Saxon

I thought it might have something to do with optimizing away the redundant conversion-to-string-and-back-to-boolean caused by using xsl:value-of rather than xsl:sequence to return the function result. But if I change the value-of to xsl:sequence it still fails in the same way, with the slightly simple expression

let $vv:v1 := normalize-space($titleVal) 
return (let $vv:v0 := bytecode($matchElement = local-name($nodeName)) 
return ValueOf(concat(replace(lower-case(normalize-space($titleVal)), " ", "_", ""), 
   xs:untypedAtomic(string(if (exists((($nodeName/preceding-sibling::node())[bytecode($matchElement = local-name($nodeName))])
[bytecode(normalize-space(xs:string(atomizeSingleton(child::element(Q{}title)))) eq $vv:v1)])) then ("42"))))))

It's going wrong during loop-lifting, but running exp.verifyParentPointers() before entry to loop-lifting shows that there's already a bad parent pointer at that point.

I've added a call to verifyParentPointers() to Optimizer.trace() (why didn't I think of that before?)

I think the problem lies in OptimizerEE.tryIndexedFilter, which starts:

            Expression k = tryToConvertFilterExpressionToKey(f, visitor, contextIsDoc);
            if (k != null) {
                return k;
            }
            if (!"EE".equals(visitor.getTargetEdition())) {
                return f;
            }
            f.restoreParentPointers();

It's finding a filter expression that is suitable for indexing, and then abandons the optimization because it's compiling for Saxon-JS, which can't handle indexed expressions. But at this point f already contains invalid parent pointers (which is why the last line of this snippet is repairing them). We should either be repairing the parent pointers on the Saxon-JS path also; or (as far as I can see) we shouldn't even attempt the tryToConvertFilterExpressionToKey() on the Saxon-JS path if we're going to ignore the result.

The method tryToConvertFilterExpressionToKey finds that the expression E[P1][P2] isn't indexable, so it decides to have a try with E[P2]{P1]. It finds this isn't indexable either, but returns the expression in an inconsistent state, which the restoreParentPointers() call is designed to repair.

It should probably copy the expression before trying to change it especially if the change is experimental. Failing that, the repair should be done by the method tryToConvertFilterExpressionToKey itself rather than leaving it to the caller. But for a patch in 9.8, the least-risk solution seems to be to move the test for a non-EE target to the start of the method.

Thanks for looking into this. Was this an issue which only manifested when doing XSLT->SEF or which could have thrown a similar error when doing XML+XSL?

The issue was specific to compiling a package with a target execution environment other than Saxon-EE.

Cool, thanks.