-
-
Notifications
You must be signed in to change notification settings - Fork 131
Fix issues with records and support instanceof final #124
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
Fix issues with records and support instanceof final #124
Conversation
|
Requesting CI testing and review. Thank you. |
grammar.js
Outdated
| 'open', | ||
| 'module', | ||
| 'record' | ||
| 'record', |
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.
Accidentally left in this trailing ,. I'll remove this when I make an update.
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.
Fixed.
|
@bmahe is this related to your recent PR? |
aryx
left a comment
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.
LGTM.
@bmahe ?
|
Could you rebase to solve the conflicts? |
2d8084f to
9fb5d40
Compare
9fb5d40 to
ee2d345
Compare
|
@aryx I rebased my branch on master and force pushed. This could use another round of testing before merging. Thank you. |
This PR continues the work of supporting Java records, letting us:
See https://docs.oracle.com/en/java/javase/18/language/records.html.
Caveat: to reduce the complexity of the grammar/parser, I defined compact constructors to be accepted at any place one might find a normal constructor, making the tree-sitter parser more permissive than the spec. I'm going by the assumption that the philosophy of tree-sitter is to understand the correct code, not to enforce it. (I could have made the
compact_constructor_declarationrule by allowing methods to have no arguments, but felt that was taking it too far.) I'm open to some guidance on this topic.Because it was convenient for me (fewer versions of generated code to keep track of), I am also adding in this PR support for the optional
finalmodifier afterinstanceof. I can't find the spec for this, but here's some communication concerning it: checkstyle/checkstyle#9897All of these issues were discovered in the Elasticsearch repo.
Checklist:
Question: while I was working out the grammar updates for records, I noticed that there is the inclusion of
recordas a "reserved identifier," along with just a couple of others. This seems pretty arbitrary and I'm wondering if they are to deal with cases where the Java language permits these keywords to be repurposed as identifiers, like with lambda arguments. I've seen this in one of the corpus tests, as well as formodulein one of the Github repos we use to test. I also see a current parse failure in the Ghidra repo wheresealedappears as a variable name undergoing assignment. So what's the general story here? Are we just opportunistically adding reserved identifiers to deal with these discoveries, and if so, isn't the naming backward (we are not "reserving keywords" but rather "un-reserving them.")?