Saxon

The problem seems to be in XSLTemplate.allocatePatternSlots(). If a pattern declares local variables and the template has mode="#all", slots are allocated in the "omniMode" (which contains all template rules) but they need to be allocated to every individual named mode.

The same problem is present in the 9.7 code, but the bug is not manifested for this test case because the predicate in the match pattern is optimised to eliminate the local variable (the predicate is reduced to [not(local-name(.))].)

I reproduced the problem on the 9.7 branch by using a pattern that was less amenable to optimization:

<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform" xmlns:xs="http://www.w3.org/2001/XMLSchema" version="2.0">
    <xsl:param name="p" select="''"/>
    <xsl:template match="*[some $item in $p satisfies $item eq local-name()]" mode="#all"/>
</xsl:stylesheet>

I have committed a patch on the 9.6 and 9.7 branches that solves this test case. Not yet regression-tested.

Added a test case match-245 to do something similar, but a bit more complex. The test passed on 9.6, but on 9.7 it failed

java.lang.UnsupportedOperationException: Cannot copy a variable reference whose binding is unknown
	at net.sf.saxon.expr.GlobalVariableReference.copy(GlobalVariableReference.java:42)

Fixing this involved two main changes:

(a) global variable references are now bound to the compiled GlobalVariable object earlier, allowing the variable reference to be copied when a template with mode="#all" is copied.

(b) the copying of a template rule with mode="#all" is now done within the logic of XSLTemplate after calling RuleManager.setTemplateRule(), rather than from within the code of RuleManager.setTemplateRule(). This allows the variable compiledTemplateRules to contain a list of all copies of the template rules, so that when the time comes to allocate slots for local variables this is done for all copies.

A further change has been committed to the 9.7 branch.

This patch appears to cause test case mode-1202 to fail.

The new code was bypassing the code in RuleManager.setTemplateRule() which splits a union pattern and allocates a default priority. Test case mode-1202 is fixed by changing the call on Mode.addRule() to call RuleManager.setTemplateRule().

Looking at the code, I am also concerned that RuleManager.setTemplateRule(), when it breaks a union pattern into its separate sub-patterns, appears to allocate the same priority to each of them, whereas the whole point is that the subpatterns can have different default priorities. Exploring more closely with the debugger, it works by accident: UnionPattern.getDefaultPriority() returns NaN, and this means that the recursive call to register each subpattern makes a second call on getDefaultPriority() - the code which gets the default priority for the union pattern is redundant but not wrong. I have removed this code on the 9.7 branch, with no ill-effects.

Bug fix applied in the Saxon 9.7.0.2 maintenance release

Leave open until fix applied in the 9.6 branch

Bug fix applied in the Saxon 9.6.0.9 maintenance release.