Project

Profile

Help

Bug #6279

closed

Incorrect optimization of generate-id() comparisons

Added by Andy Yar about 1 year ago. Updated 5 months ago.

Status:
Closed
Priority:
Normal
Assignee:
Category:
XPath conformance
Sprint/Milestone:
-
Start date:
2023-12-04
Due date:
% Done:

100%

Estimated time:
Legacy ID:
Applies to branch:
12, trunk
Fix Committed on Branch:
12, trunk
Fixed in Maintenance Release:
Platforms:
.NET, Java

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

bug.xml (168 Bytes) bug.xml Input demo data Andy Yar, 2023-12-04 13:59
test.xsl (585 Bytes) test.xsl Andy Yar, 2023-12-04 13:59
Actions #1

Updated by Michael Kay about 1 year 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.

Actions #2

Updated by Michael Kay about 1 year 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
Actions #3

Updated by Michael Kay about 1 year 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.

Actions #4

Updated by Michael Kay about 1 year ago

Now fixed except in the "export" case.

I've added XSLT test cases expression-0805 and expression-0806 that demonstrate this.

Actions #5

Updated by Michael Kay about 1 year ago

  • Status changed from In Progress to Resolved
  • Applies to branch trunk added
  • Fix Committed on Branch 12, trunk added
Actions #6

Updated by O'Neil Delpratt 5 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

Also available in: Atom PDF