Saxon

I suspect this is another symptom of bug #6022.

12.3 errors out the same way despite #6022 being closed as fixed.

$ java -cp ./SaxonHE12-3J/saxon-he-12.3.jar net.sf.saxon.Query -q:repro-issue-multiple-boolean.xq
<?xml version="1.0" encoding="UTF-8"?>net.sf.saxon.trans.UncheckedXPathException: Effective boolean value is not defined for a sequence of two or more items starting with a boolean
	at net.sf.saxon.expr.Literal$LiteralElaborator.elaborateForBoolean(Literal.java:911)
	at net.sf.saxon.functions.BooleanFn$BooleanFnElaborator.elaborateForBoolean(BooleanFn.java:166)
	at net.sf.saxon.expr.elab.BooleanElaborator.elaborateForPull(BooleanElaborator.java:24)
	at net.sf.saxon.expr.elab.Elaborator.lazily(Elaborator.java:117)
	at net.sf.saxon.expr.FunctionCall$FunctionCallElaborator.allocateArgumentEvaluators(FunctionCall.java:659)
	at net.sf.saxon.expr.SystemFunctionCall$SystemFunctionCallElaborator.setExpression(SystemFunctionCall.java:587)
	at net.sf.saxon.expr.Expression.makeElaborator(Expression.java:1761)
	at net.sf.saxon.expr.instruct.Choose$ChooseExprElaborator.elaborateForPush(Choose.java:1163)
	at net.sf.saxon.query.XQueryExpression.processQuery(XQueryExpression.java:495)
	at net.sf.saxon.query.XQueryExpression.run(XQueryExpression.java:473)
	at net.sf.saxon.s9api.XQueryEvaluator.run(XQueryEvaluator.java:464)
	at net.sf.saxon.Query.runQuery(Query.java:1001)
	at net.sf.saxon.Query.doQuery(Query.java:457)
	at net.sf.saxon.Query.doQuery(Query.java:516)
	at net.sf.saxon.Query.main(Query.java:107)
Caused by: net.sf.saxon.trans.XPathException: Effective boolean value is not defined for a sequence of two or more items starting with a boolean
	at net.sf.saxon.expr.parser.ExpressionTool.ebvError(ExpressionTool.java:767)
	at net.sf.saxon.expr.parser.ExpressionTool.effectiveBooleanValue(ExpressionTool.java:677)
	at net.sf.saxon.value.SequenceExtent$Of.effectiveBooleanValue(SequenceExtent.java:184)
	at net.sf.saxon.expr.Literal$LiteralElaborator.elaborateForBoolean(Literal.java:908)
	... 14 more
Fatal error during query: net.sf.saxon.trans.UncheckedXPathException: Effective boolean value is not defined for a sequence of two or more items starting with a boolean

Sorry about failing to fix it. I'm seeing the error running using HE 12.3 from the command line; I'm not seeing any failure in EE, even with -opt:0.

I've now reproduced it in an IntelliJ project built over the HE preprocessed source code.

Choose.elaborateForPush() is calling elaborateForPush() on its operands without any indication that dynamic errors must be masked; in consequence Concat.elaborateForPush() is calling FunctionCall.allocateArgumentEvaluators(), which calls makeElaborator(lazily, false) on the call on the boolean() function. The second argument here (false) indicates that lazy evaluation is not required - but in this case, lazy evaluation is required.

Simply changing this to say "true" unconditionally would probably have unacceptable performance implications; we somehow need to pass down the fact that the expression is guarded and mustn't fail at this stage.

The path being taken on EE looks very similar - I haven't yet worked out why one succeeds and the other fails.

The difference between HE and EE is rather strange - it appears that HE is inlining the variable $testResult, and EE is not. That needs to be investigated as a separate problem.

The underlying problem though is that we're throwing an exception when elaborating the expression boolean((true(), true()) when we discover that this can never be successfully evaluated. I don't think we should ever be throwing an error during expression elaboration.

Fixed the various elaboration methods in LiteralElaborator so any exception caught while evaluating the literal is retained and thrown at evaluation time.

Now looking at the question of why HE inlines the variable value and EE doesn't.

Wrong diagnosis, I was running EE with -opt:0 which suppressed the inlining.

What's actually happening when I remove this option is that Saxon-EE is detecting statically that $test-result instance of xs:boolean is false, and therefore eliminates the "then" branch of the conditional expression before trying to elaborate it. In fact it goes on to reduce the entire expression at compile time to the literal result "Got to else". That's expected behaviour. So, false alarm.