Project

Profile

Help

Bug #3992

closed

Overriding a variable in a used package fails if neither variable has an explicit declared type

Added by Michael Kay almost 4 years ago. Updated almost 4 years ago.

Status:
Closed
Priority:
Normal
Assignee:
Category:
XSLT 3.0 packages
Sprint/Milestone:
-
Start date:
2018-11-03
Due date:
% Done:

100%

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

Description

If a public global variable declared in a used package has no "as" attribute, an attempt to override the variable in a using package (with another variable that also has no "as" attribute) fails saying

XTSE3070: The declared type of the overriding variable $v is different from that of the overridden variable

The spec (ยง3.5.3.3) says the two variables must have identical declared types. This is a little open to interpretation (it could be read as saying that they must have explicit declared types).

Actions #1

Updated by Michael Kay almost 4 years ago

It is failing because it is actually comparing the inferred type of the two variables, which is different because one has been through type checking and the other has not.

Actions #3

Updated by Michael Kay almost 4 years ago

  • Status changed from New to Resolved
  • Fix Committed on Branch 9.8, 9.9 added

Resolved (for 9.8 and 9.9). For the overriding variable, in XSLGlobalVariable we now use getSourceBinding().getDeclaredType (defaulting to item()*) in place of getRequiredType() (which gives us the inferred type in the case where there is no explicit as attribute). For the overridden variable, we continue to use GlobalVariable.getRequiredType(), which seems to give the right answer.

Test case override-f-035.

Actions #4

Updated by O'Neil Delpratt almost 4 years ago

  • % Done changed from 0 to 100
  • Fixed in Maintenance Release 9.8.0.15 added

Bug fix applied in the Saxon 9.8.0.15 maintenance release. Leave open to the Saxon 9.9 maintenance release.

Actions #5

Updated by O'Neil Delpratt almost 4 years ago

  • Status changed from Resolved to Closed
  • Fixed in Maintenance Release 9.9.0.2 added

Bug fix applied in the Saxon 9.9.0.2 maintenance release.

Please register to edit this issue

Also available in: Atom PDF