Saxon

For the xsl:key declaration, slots for local variables are being allocated during the call on compileDeclaration, which is too early; this is followed by a call on opttimize(), which in this instance is triggering inlining of the stylesheet function call. Inlining the call introduces new variables, and this therefore needs to happen before slot allocation.

Will need to give some thought about how best to fix this.

I don't think 9.9.1.6 has introduced a new bug here; I think there's probably been a change which enables deeper optimization and this exposes the bug that was already there.

For other kinds of component, we allocate slots at the end of the optimize() phase rather than during compileDeclaration(), so I have changed XSLkey to do the same.

The fix appears to have side-effects, see test case key-058. It seems that on this path we are allocating slots to a variable used in the "use" expression (actually the implicit variable used for the current() function) but the stack frame size isn't being properly communicated to the run-time.

The code for building the index (KeyIndex#164) appears to be using the same context object, and therefore the same stack frame, for evaluating both the match pattern and the use expression. This is held as KeyDefinition.stackFrameMap. In XSLKey we are setting this during the compileDeclaration() processing (which is too early for new slot allocation in the use expression, which happens during optimize()).

KeyDefinition.setStackFrameMap() is called during compileDeclaration processing, and does nothing if the stack frame is empty, that is if there are no variables in the match pattern. The stack frame is then updated during optimize() processing, but it has not been registered with the key definition, so this has no effect. The solution seems to be for KeyDefinition.setStackFrameMap() to have effect even if the stack frame map is empty at the time.

This solves the problem for key-058, but we still get a slot allocation problem with key-073 and key-074. In both these tests (a) we have multiple xsl:key declarations with the same name, and (b) one of them uses a sequence constructor rather than a select expression for the "use" expression.

The problem here seems to be that we have optimized the use expression and inlined the local variables, so it no longer needs any slots, but we haven't updated the KeyDefinition with the optimized use expression, so at run-time it is executing the unoptimized form, which needs slots for variables.

Applied these two further changes to XSLKey.optimize() and to KeyDefinition.setStackFrameMap()

The changes have led to another regression; test case backwards-039. When there are several xsl:key definitions with the same name, and at least one has an effective version="1.0", the entire key is supposed to operate in backwards compatibility mode. We add key definitions to the key definition set during compileDeclaration(), and the key definition set is marked as backwards compatible as soon as we add a key definition with effective version="1.0". At this point, if backwards compatibility is set, we modify the "use" expression to convert the keys to strings. But in optimize(), it seems we are picking up the original use expression, not the modified one.

Fixed with a further change to XSLKey.optimize() - it now picks up the use expression from the key definition, rather than from its own remembered value.

Patch applied in the 9.9.1.7 maintenance release.