Bug #6448: Saxon-HE 12.4J has wrong column number in trace, unlike Saxon-EE - Saxon - Saxonica Developer Community

Actions

Send by e-mail Copy link

Bug #6448

closed

Saxon-HE 12.4J has wrong column number in trace, unlike Saxon-EE

Added by A Galtman 6 months ago. Updated 5 months ago.

Status:

Closed

Priority:

Low

Assignee:

Michael Kay

Category:

Diagnostics

Sprint/Milestone:

Start date:

2024-06-07

Due date:

% Done:

100%

Estimated time:

Legacy ID:

Applies to branch:

12, trunk

Fix Committed on Branch:

12, trunk

Fixed in Maintenance Release:

12.5

Platforms:

.NET, Java

Description

In XSpec code coverage reports, I get different results with Saxon-HE vs. Saxon-EE (v12.3, via Oxygen), even when I use -opt:0 with both. The Saxon-EE results look correct. The Saxon-HE results occur in both v12.3 and v12.4.

I have reproduction steps below that take XSpec out of the picture.

Sample XSLT¶

<?xml version="1.0" encoding="UTF-8"?>
<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform" version="3.0">
  <xsl:template match="*">
    <root> 
      <node type="on-non-empty">
        <xsl:sequence select="@nonexistent-attribute" />
        <xsl:on-non-empty>                                                     <!-- Expected miss -->
          <xsl:text>400</xsl:text>                                             <!-- Expected miss -->
        </xsl:on-non-empty>                                                    <!-- Expected miss -->
      </node>
    </root>
  </xsl:template>
</xsl:stylesheet>

Command¶

java -cp "%SAXON_CP%" net.sf.saxon.Transform -xsl:xsl-on-non-empty-01.xsl  -s:xsl-on-non-empty-01.xsl -T -opt:0 -o:result.xml 2>trace-saxon-he-12.4.xml

Resulting Trace¶

<trace saxon-version="12.4" xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
 <source node="/xsl:stylesheet" line="2" file="xsl-on-non-empty-01.xsl">
  <xsl:template match="*" line="3" column="27" module="xsl-on-non-empty-01.xsl">
   <LRE name="root" line="4" column="11" module="xsl-on-non-empty-01.xsl">
    <LRE name="node" line="5" column="33" module="xsl-on-non-empty-01.xsl">
     <ATTR name="type" line="5" column="33" module="xsl-on-non-empty-01.xsl">
     </ATTR>
     <condSeq line="6" column="22" module="xsl-on-non-empty-01.xsl">
      <xsl:text text="400" line="8" column="21" module="xsl-on-non-empty-01.xsl">
      </xsl:text>
     </condSeq>
    </LRE>
   </LRE>
  </xsl:template>
 </source><!-- /xsl:stylesheet -->
</trace>

The puzzling part of the trace is <condSeq line="6" column="22" module="xsl-on-non-empty-01.xsl"> because line 6 in XSLT is the following (i.e., column 22 is in the middle of the instruction):

        <xsl:sequence select="@nonexistent-attribute" />

Saxon-EE reports column 57, at the end of the instruction.

This may be related to https://saxonica.plan.io/issues/6428 or https://saxonica.plan.io/issues/6405, but I'm creating a new issue to be on the safe side.

Actions

Copy link

Updated by Michael Kay 5 months ago

I have reproduced the problem running from the command line with the issued JAR file. I haven't yet been able to reproduce it in the IDE (running with EE code but no license file doesn't trigger the error). It's therefore going to be a bit tricky to debug.

Actions

Copy link

Updated by Michael Kay 5 months ago

It's not entirely obvious what should be traced here. The condSeq expression actually represents a sequence of instructions, and the EE code appears to be giving the location of the first instruction in the sequence (in this example, there is only one instruction).

During compilation, the new ConditionalBlock instruction takes its location from the location of its first child. In the HE code this is already incorrect (6/22 rather than 6/57)

If I display the line/column of all the elements in the sequence constructor, the line number/column number on the xsl:sequence instruction appear to be correct (6/57)

I'm now displaying the line/column of both the node in the stylesheet tree, and the instruction compiled from it. In HE, for the xsl:sequence instruction, I'm getting 6/57 for the element node, and 6/22 for the compiled instruction.

I've traced it back to the point at which we parse the xsl:sequence/@select expression, which is coming back in EE with location 6/57 and in HE with 6/22.

I have found where the EE and HE paths diverge: EE is using an accelerated XPath parser that handles short simple XPath expressions (like @nonexistent-attribute) by pattern recognition, without full parsing. Perhaps I can now make faster progress by disabling this feature in the IDE.

Actions

Copy link

Updated by Michael Kay 5 months ago

The (non-accelerated) XPath parser is calculating a composite location for the select attribute: a NestedLocation comprising an AttributeLocation which identifies the container as the select attribute of the xsl:sequence element at 6/57, and an offset of 22 which is intended to represent a position within this attribute. (This offset can be useful when dealing with very long XPath expressions). But somehow the offset of 22 is being used in place of the element's column number. I imagine this happens when we drop the xsl:sequence node (which merely provides the value of its only operand) from the expression tree.

The problem is that when the location is a NestedLocation, location.getColumnNumber() returns the local offset, 22.

So we've found the problem, but the solution may not be easy, because there will be calling code that expects this result.

Actions

Copy link

Updated by Michael Kay 5 months ago

The StandardErrorReporter handles this by recognising different kinds of Location object and handling them differently. This ought not to be necessary, it means that we have a leaky abstraction. But without redesigning the abstraction, I think the best we can probably do in the short term is for the TraceListener to do the same leak-plugging that the StandardErrorReporter is doing.

Actions

Copy link