-
-
Notifications
You must be signed in to change notification settings - Fork 355
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: fix: Adjust the source position for annotated enum values #4780
Conversation
The source position is not computed correctly when an enum value/constructor call is annotated
There might be annotations on an enum field/constructor call, the source position starts after these enum
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 for your work. The fix looks good, but I got a question about one test and a few things that could be changed.
@@ -420,6 +420,13 @@ SourcePosition buildPositionCtElement(CtElement e, ASTNode node) { | |||
AllocationExpression allocationExpression = (AllocationExpression) node; | |||
if (allocationExpression.enumConstant != null) { | |||
FieldDeclaration fieldDeclaration = allocationExpression.enumConstant; | |||
|
|||
Annotation[] annotations = allocationExpression.enumConstant.annotations; |
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.
There are comments below, starting with 1)
. I think it would make sense to add one for annotations too and change the numeration accordingly.
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.
Agreed, I have updated the comments as proposed
FileUtils.deleteDirectory(OUTPUT_PATH.toFile()); | ||
} | ||
|
||
@Test |
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.
GithubIssue
already serves as test annotation, so @Test
can be removed.
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, I have removed the redundant test annotation
import org.apache.commons.io.*; | ||
import org.hamcrest.*; | ||
import org.junit.*; | ||
import static org.junit.Assert.*; |
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.
You should avoid using JUnit 4. The assertThat
method should be imported from org.hamcrest.MatcherAssert
instead.
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 started from another test in the same package, but yes it's better to write the new unit tests with JUnit 5. I have updated it
assertThat("Output file for " + path + " should exist", OUTPUT_PATH.resolve(path).toFile().exists(), | ||
CoreMatchers.equalTo(true)); | ||
|
||
String content = new String(Files.readAllBytes(OUTPUT_PATH.resolve(path)), StandardCharsets.UTF_8); |
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.
Very minor nitpick: You can use Files.readString(...)
here, which also defaults to UTF-8 directly.
Thanks for looking into it, if that's OK I'll remove the test in PositionTest.java |
readString() already returns a String
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 we need a contract comment on the first line of the method, though I'm not sure if it's needed in combination with the @GitHubIssue
annotation. I'll let an integrator decide :p.
Otherwise, this looks good to me.
Fixes #4332 btw. |
"Cannot compare this:...
when trying to print the code with SniperThe fix seems to work but I have very very little experience on the project so this might very well be misguided, there really seem to be a bug though!