Bug #5312: Cannot compile consume: net.sf.saxon.expr.ConsumingOperand cannot be cast to net.sf.saxon.expr.SuppliedParameterReference - Saxon - Saxonica Developer Community

Actions

Send by e-mail Copy link

Bug #5312

closed

Cannot compile consume: net.sf.saxon.expr.ConsumingOperand cannot be cast to net.sf.saxon.expr.SuppliedParameterReference

Added by Michael Kay about 2 years ago. Updated about 2 years ago.

Status:

Closed

Priority:

Normal

Assignee:

Michael Kay

Category:

Streaming

Sprint/Milestone:

Start date:

2022-02-12

Due date:

% Done:

100%

Estimated time:

Legacy ID:

Applies to branch:

10, 11, trunk

Fix Committed on Branch:

10, 11, trunk

Fixed in Maintenance Release:

11.2, 10.7

Platforms:

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)

Actions

Copy link

Updated by Michael Kay about 2 years ago

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.

Actions

Copy link

Updated by Michael Kay about 2 years ago

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.

Actions

Copy link

Updated by Michael Kay about 2 years ago

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.

Actions

Copy link

Updated by Michael Kay about 2 years ago

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.

Actions

Copy link