Project

Profile

Help

Problem with Tracing XPathExpressions

Added by Farid Ghanbari over 5 years ago

Hi Saxon Community,

I'm using Saxon-HE 9.9.1-1 for a code coverage tool for XQuery/XPath. I used the Saxon XQueryCompiler and a CodeInjector to process the expressions in XQuery files and I'm facing a problem with XPathParser for the following expression:

$a/x/text()

The method parseExprSingle in XPathParser doesn't return the above line as an Expression, so the coverage tool skips the XPath Expression while it's being covered.

Is there something I can do to get this working?

Thanks! Farid

Test.java (1.27 KB) Test.java

Replies (5)

Please register to reply

RE: Problem with Tracing XPathExpressions - Added by Michael Kay over 5 years ago

Sorry for the delay in responding.

The code injector mechanism is a little bit arbitrary about where it injects trace points. Primarily they are injected around constructs that correspond to "instructions" in the XSLT sense: things that create nodes or affect the flow of control, e.g. branches in a conditional instruction. I think that if we sprinkled them at a finer granularity then there could be a severe performance impact, so I don't think we should put them around every path expression, arithmetic expression, etc.

(I notice that the code injector does wrap numeric and string literals. That's purely for our own internal purposes, because we use this to modify tests prior to execution to inhibit optimization rewrites. This rather goes to show how pragmatic the whole design is...)

I think there should probably be a trace point around the main expression in an XQuery body, and that would certainly have no performance implications.

RE: Problem with Tracing XPathExpressions - Added by Michael Kay over 5 years ago

Will be fixed in the next maintenance release, see https://saxonica.plan.io/issues/4182

RE: Problem with Tracing XPathExpressions - Added by Farid Ghanbari over 5 years ago

Thanks for your answer and creating the issue.

Exactly, the injector works well with literals and numeric. Considering path expressions would be nice for my tool, because I'm getting some files for coverage, which have only path expressions. I will follow the issue and the next maintenance release :)

RE: Problem with Tracing XPathExpressions - Added by Michael Kay over 5 years ago

Come to think of it, it would do no harm to call the CodeInjector for a wider range of expressions, because a specific CodeInjector can always decide to do nothing in the case of expressions that it isn't interested in.

RE: Problem with Tracing XPathExpressions - Added by Farid Ghanbari over 5 years ago

That's right, after I encountered the problem that was what I first thought as a solution, a supertype of expression, but I found the restriction in the injector.

    (1-5/5)

    Please register to reply