-
Notifications
You must be signed in to change notification settings - Fork 332
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
JavaVisitors should visit modifiers #3502
Comments
Good to see you're back @AlexanderSkrock ; hope all is well. I'll tag @knutwannheden for review; typically we're very careful adding in new API surface, but we can discuss what you need and how best to approach that. |
Thank you for that! I totally understand. I added both a test case and a possible default implementation for visiting modifiers. Looking forward to hear your thoughts! |
We recently closed a very similar PR because we concluded that we didn't need it: @sambsnyd What are your thoughts on the use case described here? |
I would like to add that visiting modifiers would be an enhancement but the fact, we do not deeply visit child elements is rather a bug as we simply do not detect and visit occurences of annotations. For various recipes this could end in invalid results or non-compilable code. Though, I have to admit that usage of annotation on modifiers is rarely seen. |
Quick note: @Override
public @Nullable J visit(@Nullable Tree tree, ExecutionContext executionContext) {
if (tree instanceof J.Modifier modifier) {
return modifier.withAnnotations(ListUtils.map(modifier.getAnnotations(), it -> visitAndCast(it, executionContext)));
}
return super.visit(tree, executionContext);
} |
I ended up adding
to a visitor to make sure the annotations get visited. Any chance a similar step could be added to the the visitMethod and visitClass definition in JavaVisitor, or as above the visit method? |
Thanks all for the helpful context, suggestions and patience! |
What problem are you trying to solve?
While solving #2838 I realized that modifiers are currently not properly visited. In consequence I can neither react to approached modifiers by marking nor can I discover annotations on these modifiers as we stop visiting on modifier-level.
To further illustrate, the following test case shows how modifiers are not visited properly. A testcase exactly for "not visiting" modifiers was not possible as the method does not exist yet, but here we try to visit the annotation which is a sub element of our modifier.
Describe the solution you'd like
public J visitModifier(J.Modifier modifier, P p)
. Also, this should delegate two visit child elements such as annotations.Have you considered any alternatives or workarounds?
They are translated into
J.Modifier
but as they are not visited separately there is no work around.Additional context
This one is necessary to solve the last few issues with annotations on modifiers in #2838
The text was updated successfully, but these errors were encountered: