-
Notifications
You must be signed in to change notification settings - Fork 777
Nullness: ignore Jakarta Validation #5406
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
base: master
Are you sure you want to change the base?
Conversation
Teach checks like `MultipleNullnessAnnotations` and `RedundantNullCheck` to disregard annotations that look like nullness specification annotations but that actually are not; namely the Jakarta Validation `@NotNull` constraint. Resolves: google#4334
|
https://errorprone.info/bugpattern/RedundantNullCheck has the same limitation as #4334, but it's more disruptive because it happens at the call site instead of at the declaration site, and dangerous because the flagged null check is actually necessary. It would be swell to have some solution to that (and I'm probably looking at having to disable There are a few other constraint annotations that match "null" but I believe none of those are an issue. Unfortunately I'm not aware of any other offenders either, so the case is not very strong. |
| <artifactId>jakarta.validation-api</artifactId> | ||
| <version>3.1.0</version> | ||
| <scope>test</scope> | ||
| </dependency> |
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.
It looks like the test framework can create additional files on the side. That could probably be used to simulate the names as an alternative to pulling in a dependency.
|
|
||
| public static ImmutableList<AnnotationTree> annotationsRelevantToNullness( | ||
| List<? extends AnnotationTree> annotations) { | ||
| // Missing support for FALSE_NULLNESS_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.
I'm not sure what to do about this or how much it matters. There are test cases that hit this method but none that hit the MemberSelectTree inside simpleName(AnnotationTree). I can get a qualified name from a MemberSelectTree but I don't see how that can be accomplished for an IdentifierTree.
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.
That must be what Matchers::isType is for. This looks like it could work:
private static final Matcher<AnnotationTree> NOT_FALSE_NULLNESS_ANNOT =
Matchers.not(
Matchers.anyOf(FALSE_NULLNESS_ANNOTATIONS.stream().map(Matchers::isType).toList()));
public static ImmutableList<AnnotationTree> annotationsRelevantToNullness(
List<? extends AnnotationTree> annotations, final VisitorState state) {
return annotations.stream()
.filter(a -> NOT_FALSE_NULLNESS_ANNOT.matches(a, state))
.filter(a -> ANNOTATION_RELEVANT_TO_NULLNESS.test(simpleName(a)))
.collect(toImmutableList());
}but requires passing VisitorState to (one) annotationsRelevantToNullness.
For your consideration: commonquail@67be368
Teach checks like
MultipleNullnessAnnotationsandRedundantNullCheckto disregard annotations that look like nullness specification
annotations but that actually are not; namely the Jakarta Validation
@NotNullconstraint.Resolves: #4334