Implement a simple nullaway wrapper plugin#2382
Conversation
This plugin can be applied with the baseline-error-prone plugin, it adds a standardized nullaway configuration to the project with centrally managed nullaway versioning via gralde-baseline. Note that Nullaway is applied at `WARNING` rather than `ERROR` such that projects that already enforce warnings will fail builds on nullaway, however the nullaway warnings will only produce console churn otherwise.
Generate changelog in
|
…gins/BaselineNullAway.java
| - org.checkerframework.dataflow.qual.Pure | ||
| - org.checkerframework.dataflow.qual.Pure$Kind | ||
| - org.checkerframework.dataflow.qual.SideEffectFree | ||
| - org.checkerframework.dataflow.qual.TerminatesExecution |
There was a problem hiding this comment.
This roughly matches the baseline-class-uniqueness failures in baseline-error-prone. Seems fine, especially for build-only code.
…gins/BaselineNullAway.java
| } | ||
|
|
||
| private static void configureErrorProneOptions(Project proj, Action<ErrorProneOptions> action) { | ||
| proj.afterEvaluate(new Action<Project>() { |
There was a problem hiding this comment.
This is a bit gross, but required due to the way the errorprone plugin configures JavaCompile tasks. At this point it may be simpler to implement the errorprone plugin ourselves (now that the errorprone-javac dep isn't needed, and we support jdk11+)
There was a problem hiding this comment.
Does errorprone also use afterEvaluate? If so just note that the order multiple afterEvaluates run is technically undefined.
There was a problem hiding this comment.
Hmm, this may not be necessary here, I'm not entirely sure why it was required in another plugin we worked on recently. I'll remove the afterEvaluate.
schlosna
left a comment
There was a problem hiding this comment.
Overall seems reasonable, but have a concern about version pins
| configureErrorProneOptions(project, new Action<ErrorProneOptions>() { | ||
| @Override | ||
| public void execute(ErrorProneOptions options) { | ||
| options.option("NullAway:AnnotatedPackages", "com.palantir"); |
There was a problem hiding this comment.
I guess we need to provide a default package to make this work out of the box per https://github.com/uber/NullAway/wiki/Configuration#annotated-packages so this seems reasonable, though any non-Palantir projects would need to override this to enable NullAway for their code.
It would be nice to include some other commonly used packages like com.google.common for Guava but that may require more opt-in work for folks adopting this from the get-go per the "Nullness annotations" bits from Guava 31.0 release specifically the NullAway bits mentioning google/guava#6126 (comment)
There was a problem hiding this comment.
Happy to add guava by default for now, it's easier to remove packages than add them.
I'd considered introspecting the maven coordinate group, and adding something like the first two segments. So net.ckozak.foo would result in net.ckozak as an annotated package. However, I think there are sufficiently many edge cases that I'd prefer to punt solving this until we need to do so.
There was a problem hiding this comment.
I kicked off https://github.com/palantir/tritium/compare/ds/guava-nullaway?expand=1 as a quick check last night and that build failed so I think adding Guava here might cause more false positives than desired by default, so we probably do want just options.option("NullAway:AnnotatedPackages", "com.palantir"); for now. Sorry for the run around on that.
There was a problem hiding this comment.
No worries, I appreciate that you called out the idea! I had just tested a snapshot on tritium and found the same thing :-)
There was a problem hiding this comment.
palantir/tritium#1570 to fix up tritium's one flagged issue
| # See the License for the specific language governing permissions and | ||
| # limitations under the License. | ||
| # | ||
| implementation-class=com.palantir.baseline.plugins.BaselineNullAway |
There was a problem hiding this comment.
I guess we haven't switched over to the gradle plugin-publish 1.0 yet on this repo, as this would need to go in the gradlePlugin implementationClass
There was a problem hiding this comment.
I think we have, but the two definition locations are merged, and likely out of sync. This is allowed due to duplicatesStrategy 'include' declared here:
gradle-baseline/gradle-baseline-java/build.gradle
Lines 129 to 131 in 2399039
I've created an issue to follow-up and migrate to the gradle-plugin definition-site: #2384
| org.checkerframework:* = 3.23.0 | ||
| com.palantir.gradle.utils:* = 0.1.0 | ||
| com.uber.nullaway:nullaway = 0.10.1 | ||
| org.checkerframework:dataflow-nullaway = 3.25.0 |
There was a problem hiding this comment.
Do we need this more specific version pin compared to above?
| org.checkerframework:dataflow-nullaway = 3.25.0 | |
| org.checkerframework:dataflow-nullaway = 3.25.0 |
| @@ -15,6 +15,8 @@ com.googlecode.java-diff-utils:diffutils = 1.3.0 | |||
| com.puppycrawl.tools:checkstyle = 10.3.2 | |||
| org.checkerframework:* = 3.23.0 | |||
There was a problem hiding this comment.
Should we bump this to 3.25.0 and remove the pin below (and maybe sort these)?
There was a problem hiding this comment.
Ah, the dependency upgrade excavator is stuck, good catch! I agree that we shouldn't pin a more specific version, keeping these in sync is helpful.
| org.checkerframework:checker-qual:3.23.0 (3 constraints: 08256088) | ||
| org.checkerframework:dataflow-errorprone:3.23.0 (4 constraints: fa3d685c) | ||
| org.checkerframework:dataflow-nullaway:3.25.0 (2 constraints: 6911b8f1) |
There was a problem hiding this comment.
See below, but the mix of 3.23.0 and 3.25.0 versions seems potentially problematic.
| .orElseGet(() -> { | ||
| log.warn("BaselineNullAway is using 'latest.release' - " | ||
| + "beware this compromises build reproducibility"); | ||
| return "latest.release"; |
There was a problem hiding this comment.
When does this ever happen? How is nullaway applied?
There was a problem hiding this comment.
This is the same logic used in baseline-error-prone. This happens when running integration tests from source, when the classpath is built up of class files rather than a jar with an Implementation-Version in the manifest.
There was a problem hiding this comment.
Do most jars like google's own error prone core jar have this manifest usually, or is this something we publish?
There was a problem hiding this comment.
No, this is used so that we can publishToMavenLocal prior to running tests, then resolve our own checks from the mavenLocal() repo to test them.
| @Override | ||
| public void apply(Project project) { | ||
| project.getPluginManager().withPlugin("com.palantir.baseline-error-prone", _unused0 -> { | ||
| project.getPluginManager().withPlugin("java-base", _unused1 -> { |
There was a problem hiding this comment.
Updated from java to java-base as I believe that's more general
###### _excavator_ is a bot for automating changes across repositories. Changes produced by the roomba/latest-baseline-oss check. # Release Notes ## 4.164.0 | Type | Description | Link | | ---- | ----------- | ---- | | Improvement | The `CyclomaticComplexity` check is now configured with `switchBlockAsSingleDecisionPoint`. | palantir/gradle-baseline#2383 | ## 4.165.0 | Type | Description | Link | | ---- | ----------- | ---- | | Improvement | Implement a simple nullaway wrapper plugin `com.palantir.baseline-null-away` which registers the `NullAway` check at `WARNING`. Projects which fail on warnings will require this to pass pre-merge. | palantir/gradle-baseline#2382 | ## 4.166.0 _Automated release, no documented user facing changes_ To enable or disable this check, please contact the maintainers of Excavator.
This plugin can be applied with the baseline-error-prone plugin, it adds a standardized nullaway configuration to the project with centrally managed nullaway versioning via gralde-baseline. Note that Nullaway is applied at
WARNINGrather thanERRORsuch that projects that already enforce warnings will fail builds on nullaway, however the nullaway warnings will only produce console churn otherwise.==COMMIT_MSG==
Implement a simple nullaway wrapper plugin
com.palantir.baseline-null-away==COMMIT_MSG==