Project

Profile

Help

Bug #1732

closed

Incorrect type inference for attribute node tests

Added by Michael Kay about 11 years ago. Updated almost 11 years ago.

Status:
Closed
Priority:
Normal
Assignee:
Category:
XSLT conformance
Sprint/Milestone:
-
Start date:
2013-04-16
Due date:
% Done:

100%

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

Description

Saxon's algorithm for computing type relationships incorrectly determines that the NameTest attribute(abc) is not a subtype of the NodeKindTest attribute(). This is because the content type inferred for attribute(abc) is AnyType, while the content type inferred for attribute() is the more precise xs:untypedAtomic.

Test case reported by Laurent Caprani on saxon-help list, 2013-04-16. The test must be run with --generateByteCode:off, though the problem has no obvious relationship to bytecode generation.

The obvious fix is to implement the method getContentType() on NameTest using essentially the same implementation as for NodeKindTest; but it's a common path so needs careful regression testing.

Actions #1

Updated by Michael Kay about 11 years ago

Caprani's test case works on Saxon 9.5 as written, but fails if we change the return type to attribute(my-attribute). This is because 9.5 has changed node.getItemType() to return a NodeKindTest, which avoids this bug, but isn't precise enough for the type checking needed in this instance. We should be checking whether the instance conforms to the type, rather than getting the type of the instance and checking if it's a subtype of the required type.

The 9.4 and 9.5 paths differ in that 9.4 gets the type of the attribute node instance using SingletonItem.getItemType(), whereas 9.5 gets it using Type.getItemType(); the former method infers a more specific type. Both methods have comments attempting to justify their approach based on the way they are used. Neither method has changed, but TypeCheckingFilter has changed to use the latter method. This should probably be reversed.

Actions #2

Updated by Michael Kay about 11 years ago

For 9.5 I have made two changes:

(a) combined the getItemType() methods in SingletonItem and in Type into one method that computes the more precise type of a node

(b) added a getContentType() method to NodeTest that returns the same result as NodeKindTest.getContentType in the case where the node kind is known.

I ran QT3 as a regression test with 26072 successes, 0 failures, so the change seems sound enough, though it doesn't test all paths, e.g. XQJ.

I will therefore make the same changes to the 9.4 branch

Actions #3

Updated by Michael Kay about 11 years ago

  • Status changed from In Progress to Resolved

Fir 9.4 I have committed only one of these changes, the change to NodeTest. This is sufficient to solve the immediate problem. The usage of Type.getItemType() is sufficiently different that I think it's safer to make to changes there without evidence of a problem.

Actions #4

Updated by O'Neil Delpratt almost 11 years ago

  • Status changed from Resolved to Closed
  • % Done changed from 0 to 100
  • Fixed in version set to 9.4.0.8

Bug now closed. Successfully applied to the Saxon 9.4.0.8 maintenance release.

Please register to edit this issue

Also available in: Atom PDF