You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
... with a syntax error saying: Unexpected int token: "-51" in the spaceless case, so presumably the problem is that lexical analysis outputs the two tokens LITERAL 42, LITERAL -51, but the parsing only works if the tokens are LITERAL 42, MINUS, LITERAL 51, i.e. the minus token should have a higher precedence than the negative integer literal token.
Full test failure output
Error: Syntax error at line 1 col 3:
42-51
^
Unexpected int token: "-51". Instead, I was expecting to see one of the following:
at Parser.feed (node_modules/nearley/lib/nearley.js:343:27)
at doParse (src/syntax/spec-utils.ts:165:24)
at /Users/gthb/git/pgsql-ast-parser/src/syntax/spec-utils.ts:182:56
at tracking (src/lexer.ts:190:16)
at Context.<anonymous> (src/syntax/spec-utils.ts:182:49)
at processImmediate (node:internal/timers:476:21)
The text was updated successfully, but these errors were encountered:
gthb
changed the title
Expression that subtracts a literal number fails to parse
Expression that subtracts a literal number without space fails to parse
Aug 8, 2023
A lexer test explicitly wants a { type: "float", value: "-.1" }. That test could simply be changed to expect the { type: 'op_minus' } followed by a positive literal, resulting from the above change.
SET TIME ZONE -9 doesn't parse because it expects only a numeric literal; this is presumably simple to allow with a parse rule.
Several expression tests expect { type: "numeric", ...} AST nodes with negative values. I think a { type: "unary", ... } result with a positive-number argument is just as valid, but if that change is undesired, this probably needs to be transformed as a special case.
The test checkInvalidExpr('42.-51'); fails — but I think that test itself is wrong, because that expression is valid: the psql command executes SELECT 42.-51 just fine.
The tests for a->>-1 and a.b->-1 hit the syntax error Unexpected op_minus token: "-". I bet that can be fixed with another case in the parse rule.
gthb
linked a pull request
Feb 27, 2024
that will
close
this issue
This existing test passes just fine:
... but adding this corresponding test for subtraction fails:
... with a syntax error saying:
Unexpected int token: "-51"
in the spaceless case, so presumably the problem is that lexical analysis outputs the two tokensLITERAL 42
,LITERAL -51
, but the parsing only works if the tokens areLITERAL 42
,MINUS
,LITERAL 51
, i.e. the minus token should have a higher precedence than the negative integer literal token.Full test failure output
The text was updated successfully, but these errors were encountered: