Project

Profile

Help

Bug #6263

open

Test case try-031 fails under Saxon-HE (try/catch with lazy evaluation)

Added by Michael Kay 5 months ago. Updated 5 months ago.

Status:
New
Priority:
Low
Assignee:
Category:
XSLT conformance
Sprint/Milestone:
-
Start date:
2023-11-28
Due date:
% Done:

0%

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

Description

The XSLT 3.0 test case try-031 is failing under Saxon-HE. The essence of the failure is that in the construct

<xsl:variable name="p" select="...."/>
<xsl:try>
   <xsl:value-of select="$p"/>
   <xsl:catch>
      <caught/>
   </xsl:catch>
</xsl:try>

an error occurring during lazy evaluation of $p is caught by the try/catch when it should not be.

The test is failing in the candidate 12.4 release but also fails in earlier releases.

Actions #1

Updated by Michael Kay 5 months ago

  • Subject changed from Test case try-031 fails under Saxon-HE to Test case try-031 fails under Saxon-HE (try/catch with lazy evaluation)
Actions #2

Updated by Michael Kay 5 months ago

Reproduced in IntelliJ by running with optimisation disabled:

java net.sf.saxon/Transform -xsl:try-031.xsl -s:try020.xml -opt:0 -t

from /Users/..../GitHub/xslt30-test/tests/insn/try

Actions #3

Updated by Michael Kay 5 months ago

Confirmed that in the EE (optimized) case, Saxon has correctly allocated an EagerLocalVariableEvaluator, which forces the error to occur outside the try/catch block.

This is because LetExpression.needsEagerEvaluation is true.

The flag is set to true during TryCatch.optimize(), where the TryCatch expression examines all the outer variables it depends on and sets them to require eager evaluation. This code is not being called with -opt:0.

However, -opt:0 is not an accurate mimicking of Saxon-HE behaviour; that should correspond to -opt:lvmt, and with those settings, TryCatch.optimize() DOES get called, and it DOES set LetExpression.needsEagerEvaluation to true. This case seems to be failing (that is, wrongly catching the error) for rather more complex reasons.

Actions #4

Updated by Michael Kay 5 months ago

Moving the code that sets eagerEvaluation from TryCatch.optimize() to TryCatch.typeCheck() solves the problem for the opt:0 case, but not for the opt:lvmt case, as one would expect from the above analysis.

Please register to edit this issue

Also available in: Atom PDF