Saxon

The problem occurs because a SortKeyDefinition (which is a pseudo-Expression node on the expression tree) does not hold its operands (that is, its children on the Expression tree) as Operand objects, but instead constructs them on demand when the operands() method is called. This has the consequence that when an operand is rewritten as part of an optimization rewrite, the rewritten expression does not find its way back into the SortKeyDefinition object. In this case the rewritten expression declares a generated local variable, and we end up with a reference to the variable in the expression tree, but not the LetExpression that binds the variable.

A quick check shows some other expressions that are constructing Operand objects dynamically during the operands() call, and which could therefore suffer from the same problem: WhichOf, MergeInstr, CompareToIntegerConstant, LocalParam, NumberInstruction, SortKeyDefinitionList, and various Pattern subclasses (where it may be safe).

I have changed SortKeyDefinition on the 9.7 branch to use Operands properly and it fixes the problem. Regression tested by running the QT3 prod-OrderByClause and XSLT3 sort test sets. Patch copied to 9.8 branch, and committed on both.

Leaving open because other expression classes need the same treatment.

I encountered this same thing running a rather complex stylesheet in eXist-db 2.2 (saxonhe-9.4.0.7). Running the same thing outside of eXist-db 2.2 using Saxon-EE 9.6.0.7 gave me no trouble.

Since the original ticket was about xquery, I just wanted to make sure this or is not the same thing that has been fixed.

Original code:

    <xsl:variable name="classifications" select="document('DECOR.xsd')/*/xs:simpleType[@name='TemplateTypes']/*/xs:enumeration" as="element()+"/>
    <xsl:for-each-group select="$allTemplates/*/ref/template" group-by="if (classification/@type) then (classification/@type)[1] else ('notype')">
        <xsl:sort select="count($classifications[@value=current-grouping-key()]/preceding-sibling::*)"/>
        ....
    </xsl:for-each-group>

I've rewritten it like below to circumvent this:

    <xsl:variable name="classifications" select="document('DECOR.xsd')/*/xs:simpleType[@name='TemplateTypes']/*/xs:enumeration" as="element()+"/>
    <xsl:for-each-group select="$allTemplates/*/ref/template" group-by="
        (if (classification/@type) then (
            count($classifications[@value=(current()/classification/@type)[1]]/preceding-sibling::*)
        ) else (
            count($classifications[@value='notype']/preceding-sibling::*)
        )) + 1">
        <xsl:sort select="current-grouping-key()"/>
        <xsl:variable name="classification" select="$classifications[position()=current-grouping-key()]/@value"/>
        ....
    </xsl:for-each-group>

Alexander, this error message is caused by a tree corruption during optimization, and there can be a wide variety of underlying causes with the same symptom: the fact that it's the same message doesn't mean it's the same bug. I'm afraid it's probably not worth our while investigating a problem that occurs on 9.4 that can't be reproduced on a more recent release.

I had to make some further changes to SortKeyDefinition to make comparison of sort keys in xsl:merge work again. Patched on 9.7 and 9.8 branches.