Saxon

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.

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

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 :)

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.

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.