Maintenance: Planio will be observing a scheduled maintenance window this Tuesday, November 5, 2024 from 03:00 UTC until 06:30 UTC to perform urgent network maintenance in our primary data center. Your Planio account will be unavailable during this maintenance window.
Bug #6279
closedIncorrect optimization of generate-id() comparisons
100%
Description
Hello,
We have encountered a discrepancy between results produced using a standard Saxon-EE 12.4 with and without -opt:0
.
The behavior is likely related to the equality of empty.
java -jar saxon-ee-12.4.jar -xsl:test.xsl -s:bug.xml -o:standard.xml
java -jar saxon-ee-12.4.jar -xsl:test.xsl -s:bug.xml -o:noopt.xml -opt:0
We have tested positive Saxon EE 12.3 and 12.4.
Files
Updated by Michael Kay 11 months ago
Thanks, I have reproduced the issue so it shouldn't be difficult to solve.
I believe the correct answer is the one without optimization (5) - none of the elements has a preceding element named TEST2, therefore generate-id(preceding::TEST2)
should return a zero-length string, so the predicate [generate-id(preceding::TEST2[1]) = generate-id(current()/preceding::TEST2[1])]
is equivalent to ["" = ""]
which is of course true.
The optimizer is turning the comparison generate-id(X) = generate-id(Y)
into X is Y
, which is incorrect in the case where both X and Y are empty sequences.
Updated by Michael Kay 11 months ago
- Subject changed from Different results with optimizations on/off using Saxon-EE 12.4 to Incorrect optimization of generate-id() comparisons
- Category set to XPath conformance
- Status changed from New to In Progress
- Assignee set to Michael Kay
- Priority changed from Low to Normal
- Platforms .NET, Java added
Updated by Michael Kay 11 months ago
The class IdentityComparison has a flag generateIdEmulation which should be set when it is being used to compare generateId results rather than for a pure "is" test. It seems that this flag is set, but it is being ignored when the expression is "elaborated".
In passing I note that this flag doesn't seem to be reflected in the SEF export file -- which probably means that there are tests missing in this area.
I also observe that the filter expression isn't being classified as a "simple boolean filter", which means it doesn't take a fast path for such cases.
Updated by Michael Kay 11 months ago
Now fixed except in the "export" case.
I've added XSLT test cases expression-0805 and expression-0806 that demonstrate this.
Updated by Michael Kay 11 months ago
- Status changed from In Progress to Resolved
- Applies to branch trunk added
- Fix Committed on Branch 12, trunk added
Updated by O'Neil Delpratt 4 months ago
- Status changed from Resolved to Closed
- % Done changed from 0 to 100
- Fixed in Maintenance Release 12.5 added
Bug fix applied in the Saxon 12.5 Maintenance release.
Please register to edit this issue