Project

Profile

Help

Bug #3319

closed

<xsl:sequence select="accumulator-after()"/>

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

Status:
Closed
Priority:
Normal
Assignee:
-
Category:
Streaming
Sprint/Milestone:
-
Start date:
2017-06-28
Due date:
% Done:

100%

Estimated time:
Legacy ID:
Applies to branch:
9.8
Fix Committed on Branch:
9.8
Fixed in Maintenance Release:
Platforms:

Description

The rules for accumulator-after() say (ยง19.8.9.1, rule 8): If no enclosing node N of the function call has a preceding sibling node P such that (a) N and P are part of the same sequence constructor, and (b) the sweep of P is consuming, then the function call is consuming. (The term enclosing node is defined above.)

But Saxon normally carries out streamability assessment after simplifying and optimizing the expression tree, and this process collapses <xsl:sequence select="accumulator-after()"/> into a single node on the tree. In evaluating this rule we are looking only for preceding-siblings of ancestors (in the expression tree) of the call on accumulator-after(); but in this case, after the above rewrites, the consuming instruction is a preceding-sibling of the function call itself, not of any parent instruction.

Originally raised here: https://saxonica.plan.io/boards/3/topics/6837?r=6842

Actions #1

Updated by Michael Kay about 7 years ago

  • Description updated (diff)
Actions #2

Updated by Michael Kay about 7 years ago

Fixing the code that implements this rule to start searching at the function call itself, rather than at its parent instruction, fixes the problem for the normal case. However, when running with FeatureKeys.STRICT_STREAMABILITY set, the code is still reported as non-streamable, which appears incorrect.

STRICT_STREAMABILITY (a) suppresses some very early optimizations, like the elision of the node representing the xsl:sequence instruction from the tree, and (b) causes an early check on streamability before the main optimization pass. This early streamability check is passing. However, the xsl:sequence node is then elided during optimization, and we do another streamability check after optimization to build the actual execution plan, and this second check is failing because the "strict" flag is still set. It should probably only be set during the initial check.

Actions #3

Updated by Michael Kay about 7 years ago

  • Category set to Streaming
  • Status changed from New to Resolved
  • Priority changed from Low to Normal
  • Applies to branch 9.8 added
  • Fix Committed on Branch 9.8 added

Fixed the streamability analysis both with default checking and with STRICT checking.

Actions #4

Updated by O'Neil Delpratt about 7 years ago

  • % Done changed from 0 to 100
  • Fixed in Maintenance Release 9.8.0.3 added

Bug fix applied in the Saxon 9.8.0.3 maintenance release.

Actions #5

Updated by O'Neil Delpratt about 7 years ago

  • Status changed from Resolved to Closed

Please register to edit this issue

Also available in: Atom PDF