Saxon

In fact -opt:-j is sufficient to trigger it. It's happening during compilation of the template rule, which is being copied because it has both a match and a name attribute, so one copy is optimised for invocation-by-name and the other for invocation-by-pattern. The opt:-j option suppresses just-in-time template rule compilation, i.e. it forces eager (early) compilation.

Well, I can see clearly what's happening, but it requires some thinking to see how to fix it. Thanks for putting together such a simple repro: when presented like this it's hard to believe that the failure isn't happening all the time, but as you say in the report there are a number of conditions that have to occur together to trigger the fault.

When the template rule is changed to

<xsl:template name="unused" match="/*"><a a="{$test}"/></xsl:template>

Then it all works time, so I'm studying that case to remind myself how it's supposed to work. In this case, while we are parsing the XPath expression (using a fast-path XPath parser, as it happens, that recognises simple expressions like $test without doing a full parse), we call env.bindVariable(name), and this locates the global xsl:variable and registers a (forwards) reference to it. Later, we process all components in order, including the xsl:template, and call fixupReferences() recursively to find all outgoing component references in that template, which should find the variable reference and update it to point to the compiled global variable.

With the attribute value template StyleElement.fixupReferences() processes the global variable and finds one reference to the variable. With the text value template, it finds that the reference list is empty.

It seems that the fixupReferences() call is happening before the expression in the TVT has even been parsed.

This is because expressions occurring in attributes are parsed during the first pass over the stylesheet (the prepareAttributes pass), whereas expressions in TVTs are only parsed during the second pass (the validateSubtree pass).

We can't simply move all the processing of TVTs into the first pass, because the processing first parses the XPath expressions and then does type-checking, and we aren't ready to do type checking yet in the first pass. So we need to split it into two.

Doing so fixes this test case. Now need to run regression tests.

I'm seeing 3 failures from 11623 tests in the XSLT 3.0 test suite:

• accumulator-088
• forwards-011
• transform-008

These are all tests for recent bugs that are still open, and the changed code only affects XSLT, so I think we'll deem this OK.