-
Notifications
You must be signed in to change notification settings - Fork 299
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
Add Guava 31+ support by treating @ParametricNullness as @Nullable #629
Conversation
Guava versions from 31.0 onwards do away with annotating methods as returning or taking `@Nullable` if nullability depends on a type parameter. Instead adopting JSpecify semantics. For compatibility (with Kotlin, among other tools), Guava still marks such returns and arguments specially as `@ParametricNullness`. While imprecise, we can handle Guava as annotated code to at least the same level as we did previously, by treating `@ParametricNullness` as an alias for `@Nullable`, until we have full type parameter / generics support within NullAway. To test this change without bumping our own Guava dependency, we intoduce a new test target: `guava-recent-unit-tests`. Additionally, since there are actually multiple instances of `@ParametricNullness` in Guava (one per subpackage), we hard-code a check for `com.google.common.*.ParametricNullness` in our core `isNullableAnnotation(...)` check. An alternative would be to extend `-XepOpt:NullAway:CustomNullableAnnotations` to allow simple names or regular expressions, but that would make the mechanism more costly in common case. See:
Pull Request Test Coverage Report for Build #896
💛 - Coveralls |
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! Approved assuming comment is addressed before landing
*/ | ||
plugins { | ||
id 'java-library' | ||
id 'nullaway.jacoco-conventions' |
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.
If we want coverage from tests in this module to be included as part of the overall code coverage report (sent to Coveralls), we should add an implementation
dependence on this module here:
NullAway/code-coverage-report/build.gradle
Lines 90 to 95 in 4cbd781
dependencies { | |
implementation project(':nullaway') | |
implementation project(':jar-infer:jar-infer-lib') | |
implementation project(':jar-infer:nullaway-integration-test') | |
implementation project(':jdk17-unit-tests') | |
} |
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. Also making sure this builds on all JDKs we support.
Guava versions from 31.0 onwards do away with annotating methods as
returning or taking
@Nullable
if nullability depends on the typeparameter. Instead adopting JSpecify semantics for precise handling
of type parameters.
For compatibility (with Kotlin, among other tools), Guava still marks
such returns and arguments specially as
@ParametricNullness
.While imprecise, we can handle Guava as annotated code to at least the
same level as we did previously, by treating
@ParametricNullness
asan alias for
@Nullable
, until we have full type parameter / genericssupport within NullAway.
To test this change without bumping our own Guava dependency, we
introduce a new test target:
:guava-recent-unit-tests
.Additionally, since there are actually multiple instances of
@ParametricNullness
in Guava (one per subpackage), we hard-codea check for
com.google.common.*.ParametricNullness
in our coreisNullableAnnotation(...)
check.An alternative would be to extend
-XepOpt:NullAway:CustomNullableAnnotations
to allow simple names or regular expressions, but that would make
the mechanism more costly in common case.
See also: #628, google/guava#6126