Bug #2413
closed
Internal problem: Base value for indexed lookup is not indexable
100%
Description
See test case si-for-each-802.
This is a variant of si-for-each-801 changed to use xsl:stream.
The "internal problem" message is output repeatedly, but the test case completes successfully.
Changing the test to not use streaming (i.e. changing xsl:stream to xsl:for-each select=doc(...)) removes the problem.
We have an expression //node()[name() = $param] where the type of $param is not declared (so it could be a sequence of names). In the non-streaming case, we're building a key index for $param, and evaluating the predicate by looking up name() in this index. In the streaming case, data($param) is being extracted from the predicate as a local variable, which gets identified as indexable (refCount = FILTERED), but which is evaluated as a MemoClosure rather than as an IndexedValue.
Updated by Michael Kay almost 9 years ago
The problem occurs because the streaming code for local variables in LetExpressionAdjunctB is always evaluating the variable as
SequenceExtent.makeSequenceExtent(select.iterate(context))
which never creates an IndexedValue.
Updated by Michael Kay almost 9 years ago
The problem goes away by changing (in LetExpressionAdjunctB)
Sequence value = SequenceExtent.makeSequenceExtent(select.iterate(context));
to
Sequence value = ((LetExpression)getExpression()).eval(context);
However (a) this change is a little radical: it needs careful regression testing, and (b) it doesn't answer the question why the optimizer is using a local index rather than a global index.
Updated by Michael Kay almost 9 years ago
- Status changed from New to In Progress
The patch to LetExpressionAdjunctB seems good and has no adverse effects; committing it to 9.6 and 9.7. Further investigation still needed as to why we are using an IndexedLookup on this path.
Updated by Michael Kay over 8 years ago
- Category set to Internals
- Status changed from In Progress to Resolved
The index that's being created is for @data($node-name)@. The compiler thinks that $node-name could potentially be a sequence of zillions of strings, and it's worth indexing these strings to give faster evaluation of the predicate @[name() = $node-name]@. That's actually a reasonable inference.
The question is, why is data($node-name) being bound to a synthesized local variable rather than a synthesized global variable? The answer to that is in StreamInstr.promote(): it's deciding not to promote the xsl:stream instruction itself to a global variable (for good reasons), but a side-effect is that no children of the xsl:stream instruction get promoted either.
This isn't actually a bug, just a missed opportunity, and I don't think it merits fixing. Therefore closing this bug.
Updated by O'Neil Delpratt over 8 years ago
- Status changed from Resolved to Closed
- % Done changed from 0 to 100
- Fixed in version set to 9.6.0.8
Bug fix applied in the Saxon 9.6.0.8 maintenance release
Updated by O'Neil Delpratt over 8 years ago
- Applies to branch 9.6 added
- Fix Committed on Branch 9.6 added
- Fixed in Maintenance Release 9.6.0.8 added
Please register to edit this issue
.