-
-
Notifications
You must be signed in to change notification settings - Fork 370
review: Resolve references to variables declared in type patterns #6444
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
review: Resolve references to variables declared in type patterns #6444
Conversation
This approach only works for variables declared in a parent node. Note that this does not reflect the actual flow scope rules the Java compiler uses.
|
@monperrus What do you think of this PR thus far? |
|
I like the concept. You may document better the added code, esp in a big switch-style if/then/else. If the existing tests encode bad behavior, we should change them, with good comments explaining the new behavior. |
|
The approach seems good enough, although we might want to rewrite the whole logic at some point, also to not longer depend on the How are type patterns in record patterns handled? |
|
@SirYwell I'd be interested to hear your thoughts on how to better structure this logic. |
I assume that a "naive" implementation that doesn't try to re-use existing functionality (i.e., the CtQuery stuff here) would a) be easier to maintain/understand (if written in a clean way), and b) perform better, as we noticed CtQuery to have some overhead in other cases before. It might make sense to only do a rewrite when we target Java 21, as pattern matching for switch sounds like a really good fit here. Making it more explicit which action is taken for which code element (instead of the abstract "search siblings before" for example) would make the semantics clearer, and for subsequent changes (e.g., when more patterns are added to the language) it would also be clearer which changes are needed there. |
We need to visit the whole loop constructs
Variables declared within if-conditions can also be valid below if-statements. See flow scope tests in spoon.test.reference.InstanceOfReferenceTest.
They should work because this approach does a coarse search for any (nested) type pattern within an if condition, while/for loop expression or the left-hand side of a binary operator. |
|
All tests are now green. Although I'm not too happy with the code structure, I would leave it like this for now. Let me know if anyone has ideas for improvements or potential edge cases I may have forgotten ✌🏽 |
SirYwell
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.
Thanks!
|
thanks @MaxAtoms |
This adds support for variable references to local variables declared in type patterns (
spoon.reflect.reference.CtLocalVariableReference#getDeclaration).Closes #6318