-
Notifications
You must be signed in to change notification settings - Fork 1.2k
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
PatternExpr -> TypePatternExpr refactor in preparation for record pattern implementation #4387
PatternExpr -> TypePatternExpr refactor in preparation for record pattern implementation #4387
Conversation
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## master #4387 +/- ##
=============================================
- Coverage 51.912% 51.902% -0.011%
=============================================
Files 503 505 +2
Lines 28442 28461 +19
Branches 4934 4934
=============================================
+ Hits 14765 14772 +7
- Misses 11625 11636 +11
- Partials 2052 2053 +1
Flags with carried forward coverage won't be shown. Click here to find out more.
Continue to review full report in Codecov by Sentry.
|
@@ -881,4 +877,19 @@ public final boolean elidesTypeArguments() { | |||
NodeWithTypeArguments nwta = (NodeWithTypeArguments) this; | |||
return scope.elidesTypeArguments() && (!nwta.getTypeArguments().isPresent() || nwta.isUsingDiamondOperator()); | |||
} | |||
|
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.
This appears to be generated by the TypeCastingGenerator, whereas it seems to have been added manually.
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 same applies as the comment I left below regarding formatting and project configuration. I think this is generated formatting which just hasn't been included before.
javaparser-core/src/main/java/com/github/javaparser/metamodel/TypePatternExprMetaModel.java
Outdated
Show resolved
Hide resolved
|
||
/** | ||
* @return The parent context, if there is one. For example, a method exists within a compilation unit. | ||
*/ | ||
Optional<Context> getParent(); | ||
|
||
|
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 you adapt the project configuration in your IDE so as not to multiply the code modifications?
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 using the included dev-files/JavaParser-idea.xml
for my project configuration, so my IDE formatting should be up to project standards. I suspect this is a change from code generator output. When I run the code generators, it effectively rewrites every source file, even if there isn't anything new being added, resulting in a lot of style changes that aren't relevant to anything being done. I've been cherry-picking files that are actually relevant, so with this being new, it wouldn't have been included before.
The proper fix is to set up automatic formatting and run it as a commit hook, which would avoid any unnecessary style changes, but I'm not sure what the best way is to do that, both in which tools to use and how to minimise impact on open PRs. Until some kind of automatic formatting exists, I think manually removing generated formatting changes from PRs is more effort than it's worth, especially since these would have to be repeated for every new codegen PR.
javaparser-core/src/main/java/com/github/javaparser/ast/expr/PatternExpr.java
Outdated
Show resolved
Hide resolved
public PatternExpr() { | ||
} | ||
|
||
@Override |
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.
Is it normal that there is no @generated annotation? What will happen with subsequent generations? Isn't there a risk of inconsistency in the code?
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.
This is something I've noticed as well. Sometimes the @Generated
annotation is added and sometimes not. It's also not entirely consistent across runs: I've seen @Generated
added on a second or later codegen run, but I've never seen it removed.
As far as I can tell, this annotation doesn't have any effect on the generators themselves, so the risk is that contributors will edit generated code without realising it. This is not an ideal situation, but I don't know what the solution is yet. I'm still learning how the generators work myself, so I'm hoping that adding the RecordPatternExpr
class later will answer some of the questions I have as well.
TypePatternExpr typePatternExpr = expr.getPattern().get(); | ||
PatternExpr patternExpr = expr.getPattern().get(); | ||
assertInstanceOf(TypePatternExpr.class, patternExpr); | ||
TypePatternExpr typePatternExpr = (TypePatternExpr) patternExpr; |
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 you use the asTypePatternExpr() method to avoid casts?
TypePatternExpr typePatternExpr = expr.getPattern().get(); | ||
PatternExpr patternExpr = expr.getPattern().get(); | ||
assertInstanceOf(TypePatternExpr.class, patternExpr); | ||
TypePatternExpr typePatternExpr = (TypePatternExpr) patternExpr; |
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.
Idem.
@@ -142,7 +142,10 @@ public Optional<SimpleName> getName() { | |||
if (pattern == null) { | |||
return Optional.empty(); | |||
} | |||
return Optional.of(pattern.getName()); | |||
if (!(pattern instanceof TypePatternExpr)) { |
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 you use the isTypePatternExpr() method to avoid instanceof?
if (!(pattern instanceof TypePatternExpr)) { | ||
return Optional.empty(); | ||
} | ||
return Optional.of(((TypePatternExpr) pattern).getName()); |
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 you use the asTypePatternExpr() method?
javaparser-core/src/main/java/com/github/javaparser/resolution/Context.java
Outdated
Show resolved
Hide resolved
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the | ||
* GNU Lesser General Public License for more details. | ||
*/ | ||
///* |
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.
This modification is strange.
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 agree. It's probably something I added by accident with some IDE shortcut, but I've fixed it now.
...a/com/github/javaparser/symbolsolver/javaparsermodel/contexts/AbstractJavaParserContext.java
Outdated
Show resolved
Hide resolved
Very good work. Thank you very much. Based on your experience, you could create documentation in the wiki for using the generators (when, how, why use them?). |
I had the same idea when I started with this, so I kept detailed notes of everything I did for code generation for this PR. Since I'm going to add a new node type in the follow-up PR, I want to use those notes as a reference to confirm that they're correct. Once I've confirmed that, I'll update the wiki page with everything I know about code generation. |
@jlerbsc I've updated the PR to address feedback given here (although I left the whitespace changes in with a discussion about why; please let me know if you disagree). I've also included a At this point, I no longer consider the PR a WIP since I think it makes more sense to postpone further logic changes to the record patterns pr. |
There's something going on with the github runners:
|
It looks like java versions 9, 10, 12, and 14 are no longer installed correctly on the macos runners. I'll have a look and see if I can fix it |
I think https://github.blog/changelog/2024-04-01-macos-14-sonoma-is-generally-available-and-the-latest-macos-runner-image/ is the culprit. The new macos-latest runners are M1 (therefore ARM) based (https://github.com/actions/runner-images#available-images), and there aren't azul JDK ARM releases for the failing versions: https://www.azul.com/downloads/?os=macos&architecture=arm-64-bit&package=jdk&show-old-builds=true#zulu |
I've opened an exit on the project. We may have to change distrition soon. |
Do you have anything else to add to this PR? |
If you are satisfied with the changes here, then I don't have anything further to add for now. Everything else would be better suited to the record pattern pr |
See #4385 for details
This is a WIP PR and is still has some TODOs:
TypePatternExpr
is used