-
Notifications
You must be signed in to change notification settings - Fork 4.3k
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
Adds Error Prone to the maven-compiler-plugin
#2308
Conversation
Any idea why CIFuzz is failing? Is it possible that CIFuzz use Java8 and fail due the |
maven-compiler-plugin
maven-compiler-plugin
Thanks, this is great!
I think the key thing is this:
It's running with JDK 15, and I don't think Error Prone supports that. Interestingly I found an old PR that I had lost track of, where I was trying to update Guava fuzzing to use JDK 17 instead of 15. Maybe we can do something like that here too. (It would be more convincing if I had actually made that PR work.) As a short-term alternative, perhaps you could fiddle with Maven profiles so that Error Prone is not enabled if we're on JDK 15. |
I have forked oss-fuzz . I will look into the |
Hello @eamonnmcmanus, the PR google/oss-fuzz#9554 have passed all tests. Can you take a look and tell me if it’s everything good? If yes, I will mark the PR as |
That's fantastic! Thanks for taking the time to do it. |
Most welcome, now we have to wait until the PR will be merged |
Should fix the error in this [PR](google/gson#2308)
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 risky to use Error Prone with the regular compilation run, and should it be executed in a separate compilation run instead? I am a bit concerned that it hooks into compilation of classes which then end up in the final JAR. Though I am not very familiar with Error Prone, so maybe this is not an issue.
otherwise the compiler would stop at every warning that Error Prone gives us
The question might be though whether the other warnings should be fixed, suppressed or whether the severity should be adjusted for them (possibly in a follow-up PR?). Otherwise it might be difficult to notice newly introduced warnings when there are already a bunch of previously existing warnings.
@SuppressWarnings("overrides") // for missing hashCode() override | ||
static class Sandwich { | ||
@SuppressWarnings({"overrides", "EqualsHashCode"}) // for missing hashCode() override | ||
static class Sandwich { |
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.
Maybe for consistency the indentation for the complete file should be fixed? This file is not that long and the previous JUnit changes already caused some inconsistent indentation within this file too.
Or Éamonn would you prefer not to have this as part of this PR?
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 fine either way. If @MaicolAntali prefers to add suppressions in this PR and remove them later by fixing the code in one or more later PRs, that seems like a good approach.
gson/src/test/java/com/google/gson/functional/DefaultTypeAdaptersTest.java
Outdated
Show resolved
Hide resolved
<compilerArgs> | ||
<arg>-XDcompilePolicy=simple</arg> | ||
<arg>-Xplugin:ErrorProne</arg> |
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.
Should probably suppress warnings for classes generated by proto
module:
<arg>-Xplugin:ErrorProne</arg> | |
<arg>-Xplugin:ErrorProne -XepExcludedPaths:.*/generated-test-sources/protobuf/.*</arg> |
Error Prone's -XepDisableWarningsInGeneratedCode
does not seem to work because it relies on @Generated
and the protobuf plugin does not add that yet, see xolstice/protobuf-maven-plugin#29.
@@ -35,6 +35,7 @@ public void testEqualsOnEmptyArray() { | |||
} | |||
|
|||
@Test | |||
@SuppressWarnings("TruthSelfEquals") |
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 should not be suppressed, see its description.
assertThat(a).isEqualTo(a);
below should be changed to assertThat(a.equals(a)).isTrue()
(or MoreAsserts.assertEqualsAndHashCode(a, a)
?) since this is intended to explicitly test the equals
implementation.
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.
In #2299, Éamonn said we could use com.google.guava:guava-testlib
to simplify assert like this.
I never use guava-testlib
so I'm not sure how to do that. I have looked around for some documentations/examples, but I don't find nothing.
I assume we could use some like: new EqualsTester().addEqualityGroup(a).testEquals();
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.
Hmm, right. Personally I think for this PR it would be best to omit these suppressions and change the code to a.equals(a)
to fix this issue. If desired we could then add guava-testlib
in a separate PR.
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, sorry, I should have been more explicit. That is exactly what you can write, and alternatively you can have just one test method with all the different kinds of objects in different equality groups. Something like this:
new EqualsTester()
.addEqualityGroup(array1, array2) // with equal contents
.addEqualityGroup(array3, array4) // equal to each other but not array1 or array2
.addEqualityGroup(object1, object2)
...
.testEquals();
EqualsTester
tests that each object in an equality group is equal to itself and to each other object in the group, and not equal to any object in any other group. It also checks that equal objects have equal hashcodes. So it removes a lot of drudgery.
I think that would be a fine project for a separate PR.
@@ -163,6 +163,7 @@ public void testEqualsOnEmptyObject() { | |||
} | |||
|
|||
@Test | |||
@SuppressWarnings("TruthSelfEquals") |
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 should not be suppressed, see its description.
Every warn could be suppressed or fixed. If you look the build log, Error prone returns to you something like that for each warn:
You have 2 possibility: Fix it or Suppress it. If you follow the link
Exactly, The next PR(s) should fix/suppress the warns |
I see this in the CIFuzz logs:
which I think means that your oss-fuzz change isn't yet active. Otherwise we would see We don't really care about running Error Prone in the CIFuzz build. Would it be very hassly to omit it when running on JDK 15? As a workaround until the CIFuzz thing is working properly. |
@SuppressWarnings("overrides") // for missing hashCode() override | ||
static class Sandwich { | ||
@SuppressWarnings({"overrides", "EqualsHashCode"}) // for missing hashCode() override | ||
static class Sandwich { |
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 fine either way. If @MaicolAntali prefers to add suppressions in this PR and remove them later by fixing the code in one or more later PRs, that seems like a good approach.
@@ -35,6 +35,7 @@ public void testEqualsOnEmptyArray() { | |||
} | |||
|
|||
@Test | |||
@SuppressWarnings("TruthSelfEquals") |
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, sorry, I should have been more explicit. That is exactly what you can write, and alternatively you can have just one test method with all the different kinds of objects in different equality groups. Something like this:
new EqualsTester()
.addEqualityGroup(array1, array2) // with equal contents
.addEqualityGroup(array3, array4) // equal to each other but not array1 or array2
.addEqualityGroup(object1, object2)
...
.testEquals();
EqualsTester
tests that each object in an equality group is equal to itself and to each other object in the group, and not equal to any object in any other group. It also checks that equal objects have equal hashcodes. So it removes a lot of drudgery.
I think that would be a fine project for a separate PR.
I think it's fine. Error Prone doesn't affect the generated code, except that there won't be any if it detects an error. We use it in all Java compilations at Google. |
This is looking good. Thanks for the CIFuzz workaround! Let me know if this is ready to be merged. |
✅ Ready to be merged |
Should fix the error in this [PR](google/gson#2308)
* Adds Error Prone to the `pom.xml` * Adds Error Prone annotations to avoid compiling errors * Adds profile to run Error Prone in JDK8 * Revert "Adds profile to run Error Prone in JDK8" This reverts commit 61771d0. * Fix Error Prone warn * Add comment to `pom.xml` * Fix the `@SuppressWarnings("GetClassOnClass")` * Replace the Error Prone link in the `pom.xml` * Disable Error Prone with jdk-15` * Remove a new-line in `pom.xml`
First at all, I have set up the Error Prone in the
pom.xml
. I had to remove the<failOnWarning>true</failOnWarning>
otherwise the compiler would stop at every warning that Error Prone gives us.After, I have add some
@SuppressWarnings(...)
to avoid errors from Error Prone (that stop the compiler)