Saxon

It seems that in the RetainedStaticContext, the defaultFunctionNamespace is null.

Solved that problem by initializing the defaultFunctionNamespace to NamespaceConstant.FN.

But we now get a CannotCompileException attempting to compile a tail-recursive call-template instruction.

This is a consequence of the changes made for bug #4046, to permit bytecode generation for a reloaded package.

Whereas the original compilation avoids injecting BytecodeCandidates for a tail-recursive template, the package reloader is not so smart. In fact, it does not have the information to determine whether a template contains a tail call (other than by searching for it, perhaps).

Running the XSLT 3.0 tests using the XX compiler with -export:on and -bytecode:on, I get an NPE crash in -s:as -t:as-0601

java.lang.NullPointerException
	at com.saxonica.ee.bytecode.LetExpressionCompiler.compileToIterator(LetExpressionCompiler.java:141)
	at com.saxonica.ee.bytecode.util.CompilerService.compileToIterator(CompilerService.java:769)
	at com.saxonica.ee.bytecode.ChooseCompiler.compileToIterator(ChooseCompiler.java:42)

It seems that letExpr.getEvaluator() is returning null.

I don't know why the evaluator isn't set on this LetExpression. I added code to LetExpressionCompiler to make it more resilient (by using a default evaluator), but we now get invalid bytecode generated.

I've changed the exception handling for exceptions thrown by ga.endMethod() to use the same error handler used elsewhere (handleCodeGeneratorException()) - this aborts the run if Java assertions are enabled, but recovers (using interpreted code) otherwise.

Clearly this doesn't address the core issue.

Finally getting some diagnostics on the bytecode generation, though it's tough to analyse them.

The failure is in compiling the f:typeCheck() function in type.xsl line 531.

I found DocumentInstrCompiler.compileToIterator() had potential to return an EmptySequence rather than a SequenceIterator; fixed this, but it didn't solve the problem.

I devised a new debugging technique to pin down the area of failure: when we fail to compile an expression, we then attempt to compile its operand expressions, and so on recursively, until we find the smallest expression that triggers the failure. This turned out to be the very simple filter expression $diag.parts[3], and the faulty code was in FilterExpressionCompiler line 112 where it fails to duplicate a value before testing it for null.

With this change, the XSLT 3.0 test suite, using the XX compiler with bytecode enabled, is running to completion, reporting 338 test failures. Many of these are tests involving packages, which the XX compiler does not yet fully support.