-
Notifications
You must be signed in to change notification settings - Fork 62
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add operator node to AST and parser #1499
Conversation
Conformance comparison report-Cross Engine
Number failing in both: 230 Number passing in eval engine but fail in legacy engine: 203 Number failing in eval engine but pass in legacy engine: 524 Conformance comparison report-Cross Commit-EVAL
Number failing in both: 754 Number passing in Base (35271b1) but now fail: 1 Number failing in Base (35271b1) but now pass: 1 Click here to see
Click here to see
Conformance comparison report-Cross Commit-LEGACY
Number failing in both: 433 Number passing in Base (35271b1) but now fail: 0 Number failing in Base (35271b1) but now pass: 0 |
c2846a1
to
df1752b
Compare
df1752b
to
25408e4
Compare
exprNot(expr) | ||
} | ||
|
||
private fun checkForInvalidTokens(op: ParserRuleContext) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Added additional check for whitespace + comments between operator tokens. More context in this issue comment #1498 (comment)
otherOp | ||
: OPERATOR | ||
| AMPERSAND | ||
; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can we remove AMPERSAND and just have op=OPERATOR on L630?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The current ANTLR lexing and parsing logic is a bit tricky due to how we currently lex certain special characters that are also used by GPML match expressions. Currently, a single &
gets lexed as AMPERSAND
, which can have different meanings depending on its usage
- as an operator (e.g.
1 & 2
) - as part of a GPML match expression (e.g.
MATCH (x:Label&OtherLabel)
).
So this additional branch in the parsing of otherOp
allows us to also define a single &
as an operator.
I think we need to define the GPML patterns within the MATCH
clause as a separate lexing mode (more on lexer modes). This will allow us to distinguish between &
lexed as an operator node in normal expression contexts versus &
lexed as part of a GPMLMATCH
expression. For now, I'll cut an issue (#1512) and link in the lexer + parser.
OPERATOR | ||
// may not end with + or - | ||
: OpBasic+ OpBasicEnd | ||
// must include at least one of OpSpecial to end w/ anything | ||
| (OpBasic | OpSpecial)* OpSpecial (OpBasic | OpSpecial)* | ||
; | ||
|
||
fragment OpBasic | ||
: [+*=] // TODO support `<` and `>`? | ||
// comments are not matched | ||
| '-' {_input.LA(1) != '-'}? | ||
| '/' {_input.LA(1) != '*'}? | ||
; | ||
|
||
fragment OpBasicEnd | ||
: [*/=] // TODO support `<` and `>`? | ||
; | ||
fragment OpSpecial | ||
: [~@#%^?] // TODO support backtick (`)? | ||
// graph patterns are not matched | ||
| '|' {_input.LA(1) != '!'}? | ||
| '!' {_input.LA(1) != '%'}? | ||
| '&' {_input.LA(1) != '%'}? | ||
; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
For my initial read, this looks pretty good. It covers
- Don't allow +, - at end because of number signs
- Don't allow -- or /* because comments
- Don't allow GPML patterns
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yeah, that's the idea for these ANTLR semantic predicates. we can always iterate in the future to add more restrictions on operators.
"+" -> "pos" | ||
"-" -> "neg" | ||
else -> error("unsupported unary op $symbol") |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What about not !
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not aware of !
as a SQL unary operator
25408e4
to
5ad1973
Compare
Relevant Issues
Description
Other Information
Updated Unreleased Section in CHANGELOG: [NO]
v1
branchAny backward-incompatible changes? [YES]
v1
branchAny new external dependencies? [NO]
Do your changes comply with the Contributing Guidelines
and Code Style Guidelines? [YES]
License Information
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.