-
Notifications
You must be signed in to change notification settings - Fork 2.5k
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
[new-parser] Allow package to be used as an identifier #5819
Closed
Closed
Changes from all commits
Commits
File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -198,6 +198,7 @@ drlIdentifier | |
| RECORD | ||
| VAR | ||
| THIS | ||
| PACKAGE | ||
; | ||
|
||
drlKeywords | ||
|
Oops, something went wrong.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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.
@tkobayas @mariofusco @gitgabrio Together with
THIS
on the line above, this is just the tip of the iceberg. If we want to keep the new parser 100% backward compatible, we need to A) also add all the other Java keywords, for example,long
,break
,for
, etc. or B) revert closer to the old approach and stop using JavaLexer that defines all these keyword tokens.B) means using just a few tokens for operators, parentheses, and literals of various types, and
IDENTIFIER
for everything else on the Lexer level. The parser then needs to use semantic predicates (e.g.helper.validateIdentifierKey(DroolsSoftKeywords.PACKAGE)
to see whether the nextIDENTIFIER
token actually containspackage
).A) means listing all JavaLexer tokens for various Java keywords here and also replacing nearly all usages of
IDENTIFIER
withdrlIdentifier
.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 think the original test failure #5818
org.kie.declarativetypes.JavaBeansEventRoleTest#testImportBean
is a very exceptional case.The test doesn't fail with the old parser, because the package
some.other.package
doesn't have anything to compile actually. If a user adds a rule to the package, it would fail on the java compilation phase even with the old parser.DRL is more or less based on Java syntax, so I think, theoretically, it's fine to fail such a java keyword usage (which normally fails with java compiler) at the parse phase with the new parser (As written in #5818, no-error-report is another issue, though). In other words, fix the test case not to use
package
inpackage
.C) Keep excluding java keywords from
drlIdentifier
It's against the policy "100% backward compatible with the old parser", but sounds acceptable. WDYT?
(We may face a situation that we will need to choose option A or B in the future, though)
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.
Hi @yurloc @tkobayas @mariofusco
sorry I could provide only very general observations:
drlIdentifier : drlKeywords
- and then keep going with optionA
(IIUC)Wdyt ? Am I missing something ?
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.
Okay, I'm not opinionated on this. We can go with Option A and leave Option C as a future enhancement possibility.
There is no programmatic way because those Java keywords are individually declared in
JavaLexer.g4
. I think explicitly listing them indrlIdentifier
is readable enough.Thanks,
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.
ok @tkobayas
Anyway, just remember that copying/duplicating stuff creates problem of maintanability, not readability.
Anyway, fine for me 👍