Bug #4293
closedStreamability of accumulator-after in select expression of accumulator-rule with phase=end
100%
Updated by Michael Kay about 5 years ago
- Status changed from New to In Progress
Added to XSLT3 test suite as accumulator-077s.
Updated by Michael Kay about 5 years ago
We need to implement the rule
If the function call [on fn:accumulator-after()
] is contained in the select expression or contained sequence constructor of an xsl:accumulator-rule
specifying phase="end"
, then it is motionless.
The challenge is: at the point we assess the streamability of the call on accumulator-after()
, how do we know this condition is true?
Searching up the expression tree doesn't work, because this only takes us up to the outermost containing expression or instruction, it doesn't tell us where in the stylesheet that expression or instruction occurs.
We could perhaps wrap the select expression or sequence constructor of an accumulator rule in a new kind of PseudoExpression at the root of the expression tree, existing purely for this purpose.
Alternatively we could add information to the ContextItemStaticInfoEE
that we pass down the tree as we evaluate streamability. This seems a cleaner solution.
Updated by Michael Kay about 5 years ago
- Applies to branch 9.9, trunk added
- Fix Committed on Branch 9.9, trunk added
Added information to ContextItemStaticInfoEE to indicate whether we are evaluating the streamability of an accumulator rule, and if so whether the phase is START or END; this information is set during XSLAccumulator.checkRuleStreamability()
, and is read during Streamability.computeAccumulatorAfterSweep()
.
Test now passing.
Updated by Michael Kay about 5 years ago
I also took the opportunity to review various TODO messages pointing out that the spec no longer defines an error XTDE3420, though there are various places in the code that throw this error.
The first of these is in AccumulatorRegistryEE.getStreamingAccumulatorValue()
, which calls AccumulatorWatch.isDonePostDescent()
. I think this check never fires simply because we now have static rules that ensure that the situation cannot arise.
The other two are within Inversion.invertChildExpression()
and Inversion.processChildExpression()
, both called during static streamability analysis. These both look for calls on accumulator-after()
within a motionless expression; but under the revised design, a call on accumulator-after()
that is not preceded by a consuming expression is itself deemed consuming, so the containing expressions are by definition not motionless; therefore we can never go down this path.
I will leave well alone on the 9.9 branch, but on the development branch I will remove the tests for conditions that can never be satisfied.
Updated by Michael Kay about 5 years ago
- Status changed from In Progress to Resolved
Updated by O'Neil Delpratt about 5 years ago
- Status changed from Resolved to Closed
- % Done changed from 0 to 100
- Fixed in Maintenance Release 9.9.1.5 added
Bug fix applied in the Saxon 9.9.1.5 maintenance release.
Please register to edit this issue