Saxon

The AIOOB exception occurs while formatting the diagnostic stack trace, so let's deal with that one first.

The stack frame one below the top stack frame has a stack frame map saying there are two variables, but the array used to hold variables has only one entry.

So there are two parts to that problem. Firstly, it shouldn't happen. Secondly, if it does, the stack trace display should be more resilient.

I've fixed the resilience problem; the stack trace is now reporting the inconsistency and recovering, outputting:

Error at xsl:copy on line 676 column 14 of xsd.xsl:
  XTDE0410  An attribute node (processContents) cannot be created after a child of the
  containing element. Most recent element start tag was output at line 674 of module xsd.xsl
  In template rule with match="@*" on line 668 of xsd.xsl
     Focus
        Context item: /xs:schema/xs:defaultOpenContent[1]/xs:any[1]/@processContents
        Context position: 1
     Local variables
        $fqgi = doc()
     invoked by xsl:apply-templates at file:/Users/mike/bugs/2024/6598-ToveyWalsh/xsd.xsl#677
  In template rule with match="*" on line 668 of xsd.xsl
     Focus
        Context item: /xs:schema/xs:defaultOpenContent[1]/xs:any[1]
        Context position: 4
     Inconsistent stack frame: expecting 2 variables, but found 1
     invoked by xsl:apply-templates at file:/Users/mike/bugs/2024/6598-ToveyWalsh/xsd.xsl#677
  In template rule with match="*" on line 668 of xsd.xsl
     Focus
        Context item: /xs:schema/xs:defaultOpenContent[1]
        Context position: 24
     Inconsistent stack frame: expecting 2 variables, but found 1
     invoked by xsl:apply-templates (tail calls omitted) at file:/Users/mike/bugs/2024/6598-ToveyWalsh/xsd.xsl#176
  In template rule with match="/" on line 72 of xsd.xsl
     Focus
        Context item: /
        Context position: 1
     Local variables
        $doctitle = u"Schema document for  ... g/1999/XSL/Transform"
        $docIsProlific = true()
An attribute node (processContents) cannot be created after a child of the containing element. Most recent element start tag was output at line 674 of module xsd.xsl

The stack frame that is expecting 2 variables thinks that both variables are called $fqgi

I've stopped it at the applyTemplates call processing xs:defaultOpenContent in the unnamed mode. JIT template rule compilation kicks in here as its the first use of the template rule, and slots are allocated, giving (correctly) a stack frame map with one variable, for $fqgi.

My suspicion now is that this template (at line 668) has a union pattern with match="*|@*" which means there are going to be two copies of the template body for the two match patterns, and that somehow the stack frames for both are going to be intermingled.

Sure enough, when we come to handle the @processContents attribute, we find ourselves dealing with a template rule whose body is non-null (indicating it has been initialised) but whose initializer is non-null (indicating it has not). This leads to the template rule being initialised for a second time, which leads to duplicate slots being allocated -- which almost certainly does no harm until we get a failure that causes the stack trace to be printed.

I'm now looking at why the stylesheet fails in the first place, it's fairly obvious: at line 665 we have

<xsl:element name="div">
  <xsl:value-of select="concat('&lt;',name(),'>')"/>
  <xsl:copy>

and if the context node is an attribute (in this case, the @processContents attribute) the xsl:value-of will produce a text node, and the xsl:copy will then produce an attribute node. Running in the browser with a 1.0 processor this is going to be a recoverable error ("implementations may either signal the error or ignore the attribute.")

This became a non-recoverable error in 2.0:

[ERR XTDE0410] It is a non-recoverable dynamic error if the result sequence used to construct the content of an element node contains a namespace node or attribute node that is preceded in the sequence by a node that is neither a namespace node nor an attribute node.

This is a documented incompatibility: §J1.4 para 6 ("In classifying such errors as non-recoverable, the Working Group used the criterion that no stylesheet author would be likely to write code that deliberately triggered the error and relied on the recovery action.")

Wrote test case apply-templates-003.

First time through, TemplateRuleInitializer.init() calls jitCompiler, calls XSLTemplate.compileDeclaration(), which copies the compiled body to all cloned template rules, and this happens before any type checking or optimization.

The TemplateRuleInitializer then use the union pattern (in this case A|B|C) as the context item type, rather than the specific branch. As a result, the optimization of the body expression doesn't optimize away the if (. instance of element(A)) branches.

Tried changing TemplateRuleInitializer.init() so it skips much of the logic if templateRule.getBody() is non-null. This causes failures in a few tests, for example next-match-017 which fails saying "Can't elaborate a local variable reference before slot numbers have been allocated". This test doesn't involve a union pattern, it involves the same template rule being imported/included at two different precedence levels.

Generally, this code is proving a bit fragile... Any way we change it seems to break some rarely-executed path.

I now have a clearer picture of what is going wrong.

At the point we apply templates to the defaultOpenContent element, we do the lazy initialization of its template rule, building the code and creating a stackFrameMap with one variable name.

At the point we apply templates to the processContents attribute (called from within the above template), we do another lazy initialization, this time to the "clone" of the above template rule. This is where we create a new stackFrameMap, doubling up the number of slots. This is wasteful but is in itself harmless; the new stackFrameMap has two variables rather than one, but one goes unused.

The problem is that the new oversized stack frame map gets written to both clones. The first template rule, which is still being executed, now has a slot array of length 1 (based on the stack frame map at the time execution started), but has a stackFrameMap of length 2 (because it was overwritten when the clone template rule was initialized). This creates an inconsistency when the stack frame is later examined while creating the stack trace. The inconsistency probably does no harm otherwise.

It's not at all clear how best to solve the problem. A substantial redesign seems not to be the right choice, given that the symptoms are very minor and easily masked. But sticky-plaster fixes all seem to have unwanted side-effects.

I think the sensible thing to do is to have a single Initializer at the level of the XSLTemplate, rather than at the level of the individual (clone) TemplateRule, and for this to be invoked when any of the clones is needed; it should do the initialization of all of them at the same time. That's a somewhat bigger change than I would like, but smaller fixes don't seem to work.

Really it would make sense to go back to having one TemplateRule per applicable mode, rather than one per sub-pattern per mode.