Bug #5312
closed
Cannot compile consume: net.sf.saxon.expr.ConsumingOperand cannot be cast to net.sf.saxon.expr.SuppliedParameterReference
Applies to branch:
10, 11, trunk
Fix Committed on Branch:
10, 11, trunk
Fixed in Maintenance Release:
Description
Test case si-try-200 created, based on https://saxonica.plan.io/boards/3/topics/8400
Warning on line 14 column 32 of si-try-200.xsl:
SXST0067 Execution of bytecode(consume(xsl:apply-templates)) is not fully streamed
Cannot compile consume: net.sf.saxon.expr.ConsumingOperand cannot be cast to net.sf.saxon.expr.SuppliedParameterReference
java.lang.ClassCastException: net.sf.saxon.expr.ConsumingOperand cannot be cast to net.sf.saxon.expr.SuppliedParameterReference
at com.saxonica.ee.bytecode.SuppliedParameterReferenceCompiler.compileToIterator(SuppliedParameterReferenceCompiler.java:18)
On SaxonJ 10.6 when running from the command line, I get the effect reported in the forum post. A warning
Warning on line 14 column 32 of si-try-200.xsl:
SXST0067 Execution of bytecode(consume(xsl:apply-templates)) is not fully streamed
followed by incorrect output. The same occurs with SaxonJ 11.x from the command line.
SaxonCS 11.x produces correct output and no warnings, both from the command line and from the test driver.
When run on SaxonJ 10.6 from the test driver, it appears to run correctly and produce correct output.
When run on SaxonJ 11.x from the test driver, it crashes as reported above.
On further investigation, the test works fine in all environments with bytecode generation disabled, but is failing in a variety of ways with bytecode enabled.
- Status changed from New to Resolved
- Applies to branch 10, 11, trunk added
- Fix Committed on Branch 10, 11, trunk added
Normally we avoid injecting ByteCodeCandidate instructions into streamable code. For some reason related to the try/catch that isn't happening here, and we find ourselves inverting the streamable template containing a ByteCodeCandidate. The streaming code struggles with this, producing first the warning and then the incorrect output.
I've solved it by adding code to the inversion logic that skips the ByteCodeCandidate if it is encountered in the expression tree.
Although that solved it, the original crash
net.sf.saxon.expr.ConsumingOperand cannot be cast to net.sf.saxon.expr.SuppliedParameterReference
was not addressed. This is caused by the fact that the ExpressionCompilerMap maps a ConsumingOperand expression to a SuppliedParameterReferenceCompiler, which relates to the fact that in 9.6, ConsumingOperand was introduced as a replacement for SuppliedParameterReference in response to bug #2320.
I'm going to remove that entry from the map, and instead the ExpressionCompiler will skip a ConsumingOperand if it encounters one (which shouldn't happen.) I'll make this change only on the 11.x and development branches, not on 10.x.
- Fixed in Maintenance Release 11.2 added
Bug fix applied in the Saxon 11.2 maintenance release. (Leaving bug open awaiting next Saxon 10 maintenance release.)
- Status changed from Resolved to Closed
- % Done changed from 0 to 100
- Fixed in Maintenance Release 10.7 added
- Fixed in Maintenance Release deleted (
11.2)
Bug fix applied in the Saxon 10.7 maintenance release.
- Fixed in Maintenance Release 11.2 added
Please register to edit this issue
Also available in: Atom
PDF
.