true[false] doesn't return ()

Bug #1281680 reported by Ghislain Fourny
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Zorba
In Progress
Critical
Ghislain Fourny

Bug Description

null[false]

returns null (should return empty sequence).

Same for true[false], false[false], but it works fine with strings like "foo"[false].

Revision history for this message
Ghislain Fourny (gislenius) wrote :

Same for true[2], null[2], false[2]

Revision history for this message
Matthias Brantner (matthias-brantner) wrote :

It seems to be a problem in the parser.

For the query 'true[false()]', I get the following AST

<ParseNodeTree>
<MainModule pos='/home/mbrantner/zorba/build/../build/tmp.jq:1.2-15' ptr='0x1ba4a20'>
  <QueryBody pos='/home/mbrantner/zorba/build/../build/tmp.jq:1.2-15' ptr='0x1b693d0'>
    <BooleanLiteral pos='/home/mbrantner/zorba/build/../build/tmp.jq:1.2-15' ptr='0x1b7e220'>
    </BooleanLiteral>
  </QueryBody>
</MainModule>
</ParseNodeTree

which seems to completely miss the predicate.

For the query 'true()[false()] it works.

Changed in zorba:
assignee: Matthias Brantner (matthias-brantner) → Paul J. Lucas (paul-lucas)
Revision history for this message
Paul J. Lucas (paul-lucas) wrote :

Can you clarify what this is supposed to do? First, I assume this is JSONiq syntax, yes? Second, is the use of [] an array index? If yes, I assume then it's supposed to return () because the thing to which the [] is applied isn't an array, yes? If that's true, then why isn't it an error?

Revision history for this message
Matthias Brantner (matthias-brantner) wrote :

true[2] is JSONiq
true()[2] is XQuery

The latter works. The former doesn't. Please compare the resulting parse trees to see how it should be.

Changed in zorba:
status: New → In Progress
Revision history for this message
Paul J. Lucas (paul-lucas) wrote :

When it's just "true," it's not considered a function call because function calls must have (...) after them. Should the "true" be considered a synonym for "true()" in JSONiq?

Revision history for this message
Paul J. Lucas (paul-lucas) wrote :

The problem is that it reduces by the wrong rule. At the StepExpr rule (line 4317, parser.y), it chooses:

    AxisStep -> ForwardStep (AbbrevForwardStep -> NodeTest -> NameTest -> QName) PredicateList

rather than:

    PostfixExpr -> PostfixExpr (PrimaryExpr) -> PredicateList

When "true()" is used, it parses as:

    PrimaryExpr -> FunctionCall

without the "()", it fails to match PrimaryExpr. So that's the problem, but it's not clear how to fix it. Suggestions?

Changed in zorba:
assignee: Paul J. Lucas (paul-lucas) → Ghislain Fourny (gislenius)
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.