Saxon

Changing LetExpression.resetLocalStaticProperties() to set references to an empty list rather than to null seems to solve the problem, but it will need careful regression testing.

Unfortunately t

This is a consequence of the large size of the match="/" template rule.

We've been making a serious effort in 9.8 to reduce compile time, and to achieve this we looked at where large costs were being incurred during optimization. One of these was that some operations to simplify the expression tree were quadratic in the size of the expression tree, and so there are some optimizations we no longer attempt if the tree is above a certain size. This includes the elimination of a variable that is never used: for this particular case, we abandon the search after 500 nodes in the expression tree.

It's very hard to say whether we're doing the right thing here. It's all very pragmatic. However, we were seeing a significant number of use cases where we were clearly doing more work at compile time than was justified by the run-time improvements achieved, so optimizing a little less aggressively seemed a sensible thing to do.

For this particular use case it occurs to me that you have a large block of code that doesn't depend on any variables at all. We have an expression property "depends on local variables", and if that property value is trustworthy then we should be able to prune the search when looking for references to one particular variable. I'll experiment with this. The danger is that all derived information on the expression tree can get out of date as a consequence of tree rewrites.

Making this change led to four xsl:evaluate tests failing (-009, -012, -013, -014) complaining that a variable binding has been deleted when references to the variable exist. In all these cases the variable is referenced in xsl:evaluate/xsl:with-param/@select. So presumably the DEPENDS_ON_LOCAL_VARIABLES property is not being correctly set in this case.

Indeed, EvaluateInstr.computeDependencies() fails to consider the xsl:with-param children. In fact the implementation of this method is very poor: it should rely on the generic implementation which gets all the dependencies of the expression's operands, customized by supplying a getIntrinsticDependencies method that returns the intrinsic dependencies of the expression irrespective of its operands. Changing this fixes the regression.

I was doing that on the 9.8 branch, I now realise this was originally a 9.7 bug, so I need to look at the 9.7 behaviour.

I kept trying to come up with a small XSLT reproducing the problem and I kept failing because once the XSLT got smaller the problem could no longer be reproduced :)

Thanks for the fix, the problem is of course not critical for us. We integrated Saxon 9.7.0.19 with Oxygen and all the other fixes you made in the meantime seem fine, thanks for being so responsive.