Bug #1614
closed
Problem with typeswitch in XQuery?
Category:
XQuery conformance
Fixed in Maintenance Release:
Description
I am seeing Saxon XQuery processor fail with this query. To the best of my knowledge I believe the query is correct, it does seem to pass on eXist-db and Zorba XQuery Processors, although that does not mean it is correct of course!
let $something := 1 cast as xs:integer return
typeswitch($something)
case document-node() return
<result>found a document</result>
case $e as element() return
<result>found an element: {local-name($e)}</result>
case $t as text() return
<result>found the text: {$t}</result>
case $i as xs:integer return
<result>found the integer: {$i}</result>
default return
()
Files
As your Bug Tracker seems to have mangled the XQuery I posted in the message. I have attached it in a file also.
- Category set to XQuery conformance
- Assignee set to Michael Kay
- Found in version changed from HE 9.4.0.4 to 9.4
The rules on error handling and optimization in XQuery are sufficiently permissive that one could argue this behaviour is legal; but I agree that it's undesirable. What seems to be happening is that Saxon rewrites the typeswitch expression in terms of primitives such as "if $x instance of element() then local-name($x)", and then applies type checking to this rewritten expression; during this analysis it works out that $x is always an integer and local-name($x) is therefore a type error; and type errors that are detected statically can be reported statically even if they occur in code that is never executed. I'll try to find a way of fixing this; it might not be easy.
- Status changed from New to Resolved
- % Done changed from 0 to 100
I have committed a patch for this in the 9.4 branch. The effect of the patch is that during type checking of a conditional expression, if a condition is statically determined to be false, then a type error in the corresponding branch of the conditional is not reported statically (which means in effect that it is never reported -- it won't be reported dynamically because the code is never executed).
- Status changed from Resolved to Closed
- Fixed in version set to 9.4.0.6
Please register to edit this issue
Also available in: Atom
PDF