-
Notifications
You must be signed in to change notification settings - Fork 5
Issue #80: Resolve MultiVariableDeclaration Bug #104
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
Conversation
src/main/java/org/checkstyle/autofix/recipe/FinalLocalVariable.java
Outdated
Show resolved
Hide resolved
src/main/java/org/checkstyle/autofix/recipe/FinalLocalVariable.java
Outdated
Show resolved
Hide resolved
|
@rdiachenko kindly review. |
| @Override | ||
| public TreeVisitor<?, ExecutionContext> getVisitor() { | ||
| return new LocalVariableVisitor(); | ||
| return new JavaIsoVisitor<>() { |
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.
we create this anon impl JavaIsoVisitor, after that LocalVariableVisitor and MarkViolationVisitor
It looks like all of these objects have the same generic extension, and I am curious, instead of having three visitor objects, can we have only one?
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 true, that you have to visit each variable declaration twice?
The first time to mark everything, the second time to add modifiers. If so, maybe we can have two sequential visitors
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.
Yes, we visit each variable twice.
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 the correct approach IMO.
kindly see: https://docs.openrewrite.org/authoring-recipes/multiple-visitors
| } | ||
|
|
||
| public static class FinalLocalVariableMarker implements Marker { | ||
| private final UUID id; |
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.
why do we need id? couldn't find usages of this field
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.
Marker interface contains abstract method like getId() which we need to implement.
Since Id is not used i have updated the marker class as :
public static class FinalLocalVariableMarker implements Marker {
public FinalLocalVariableMarker() {}
@Override
public UUID getId() {
return null;
}
@Override
public <M extends Marker> M withId(UUID id) {
return null;
}
}| } | ||
|
|
||
| @Override | ||
| public J.Block visitBlock(J.Block block, ExecutionContext executionContext) { |
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 don't quite understand why we should specifically handle visiting blocks. My assumption was that any variable declaration node would be visited in visitVariableDeclarations?
Could you please provide an example of a variable declaration that won't be handled by visitVariableDeclarations but will be handled by visitBlock
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.
kindly see: #80
example:
int a = 1, b = 2, c = 3; // 1 violation
...
a = 7;
b = 8;multiple variable declaration can not be handled by visitVariableDeclarations.
| } | ||
|
|
||
| private final class LocalVariableVisitor extends JavaIsoVisitor<ExecutionContext> { | ||
| private final class MarkViolationVisitor extends JavaIsoVisitor<ExecutionContext> { |
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.
We definitely need more documentation around these two visitors. The logic looks cumbersome, and I think we should provide some details on how it works
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.
done.
60eda3c to
03a10eb
Compare
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.
Some suggestions could not be made:
- src/main/java/org/checkstyle/autofix/recipe/FinalLocalVariable.java
- lines 28-27
- lines 243-244
9374d70 to
d85995b
Compare
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.
Some suggestions could not be made:
- src/main/java/org/checkstyle/autofix/recipe/FinalLocalVariable.java
- lines 249-249
d85995b to
6938b2f
Compare
rdiachenko
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.
@Anmol202005 could you go to Checkstyle, take all test inputs from finallocalvariable subpackage in tests, and put them into this PR? Lots of cases are already covered by those test inputs, let's reuse them and check the recipe works expected.

6938b2f to
8d8bd4c
Compare
|
@rdiachenko done. Kindly review |
src/main/java/org/checkstyle/autofix/recipe/FinalLocalVariable.java
Outdated
Show resolved
Hide resolved
8d8bd4c to
b0371e0
Compare
rdiachenko
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
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 to merge.
@Anmol202005 , do we test compilation of Input and Output files by maven compilation ?
I see we did not, we definetely should before this project goes to massive development.
example of how we did this in main project: https://github.com/checkstyle/checkstyle/blob/1f71110827d1b2b71f4a2434ab20253d344fcbb0/pom.xml#L1462-L1473 please add in separate issue.
We shold be confident that after auto update is done, code is still compilable.
@rdiachenko @romani |
Fixes: #80.