Project

Profile

Help

Bug #4583

Failed to compile "('0', 0)[1] ! xs:integer(.)"

Added by Michael Kay about 1 month ago. Updated 24 days ago.

Status:
In Progress
Priority:
Normal
Assignee:
Category:
-
Sprint/Milestone:
-
Start date:
2020-06-13
Due date:
% Done:

0%

Estimated time:
Applies to JS Branch:
2.0, Trunk
Fix Committed on JS Branch:
Trunk
Fixed in JS Release:
SEF Generated with:
Company:
-
Contact person:
-
Additional contact persons:
-

Description

Reported on saxon-help mailing list:

Saxon-JS 2.0.2 fails to compile this simple stylesheet which 10.1J can compile and execute.

<?xml version="1.0" encoding="UTF-8"?>
<xsl:stylesheet exclude-result-prefixes="#all" version="3.0"
   xmlns:xs="http://www.w3.org/2001/XMLSchema"
   xmlns:xsl="http://www.w3.org/1999/XSL/Transform">

   <xsl:template name="xsl:initial-template">
       <i>
           <xsl:value-of select="('0', 0)[1] ! xs:integer(.)" />
       </i>
   </xsl:template>
</xsl:stylesheet>

produces:

Compiling stylesheet /tmp/test.xsl
Failed to compile stylesheet: Cannot read property 'name' of undefined
(long backtrace snipped)

History

#1 Updated by Michael Kay about 1 month ago

  • Applies to JS Branch 2.0 added

#2 Updated by Michael Kay about 1 month ago

Added test case to XSLT3 suite as predicate-057

#3 Updated by Michael Kay about 1 month ago

Problem reproduced; the failure appears to be with the expression st.itemType.underlyingType.name at line 31 of Function.js;

st.itemType is AnyItemType, so underlyingType is undefined.

This path is only looking for an optimisation opportunity, so I think it can be fixed by treating local === st.itemType.underlyingType.name as false in this case.

#4 Updated by Michael Kay about 1 month ago

  • Subject changed from Failed to compile "('0', 0)[1] ! xs:integer(.)" to Documentation - superscript not rendered

#5 Updated by Michael Kay about 1 month ago

  • Subject changed from Documentation - superscript not rendered to Failed to compile "('0', 0)[1] ! xs:integer(.)"

#6 Updated by Michael Kay 28 days ago

  • Assignee changed from Michael Kay to John Lumley

#7 Updated by John Lumley 28 days ago

  • Status changed from New to Resolved
  • Applies to JS Branch Trunk added

adding && st.itemType.underlyingType to Function.js#31 fixes the problem. Awaiting archive before committing

#8 Updated by John Lumley 28 days ago

  • Fix Committed on JS Branch Trunk added

#9 Updated by John Lumley 24 days ago

  • Status changed from Resolved to In Progress

Reopening as xs:NOTATION() is now giving a wrong error (XPST0080 rather than XPST0017)

Please register to edit this issue

Also available in: Atom PDF Tracking page