-
Notifications
You must be signed in to change notification settings - Fork 742
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
VoidMissingNullable: handle implicit parameterized types #4123
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -148,6 +148,7 @@ | |
import com.sun.tools.javac.util.Log; | ||
import com.sun.tools.javac.util.Log.DeferredDiagnosticHandler; | ||
import com.sun.tools.javac.util.Name; | ||
import com.sun.tools.javac.util.Position; | ||
import java.io.IOException; | ||
import java.lang.annotation.Annotation; | ||
import java.lang.reflect.Method; | ||
|
@@ -2645,15 +2646,18 @@ private void scan(Type from, Type to) { | |
} | ||
|
||
/** Returns {@code true} if this is a `var` or a lambda parameter that has no explicit type. */ | ||
public static boolean hasNoExplicitType(VariableTree tree, VisitorState state) { | ||
public static boolean hasImplicitType(VariableTree tree, VisitorState state) { | ||
/* | ||
* We detect the absence of an explicit type by looking for an absent start position for the | ||
* type tree. | ||
* | ||
* Note that the .isImplicitlyTyped() method on JCVariableDecl returns the wrong answer after | ||
* type attribution has occurred. | ||
* For lambda expression parameters without an explicit type, both | ||
* `JCVariableDecl#declaredUsingVar()` and `#isImplicitlyTyped()` may be false. So instead we | ||
* check whether the variable's type is explicitly represented in the source code. | ||
*/ | ||
return getStartPosition(tree.getType()) == -1; | ||
return !hasExplicitSource(tree.getType(), state); | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. We used to check I also remembered that recent versions of Thoughts on using that approach instead of delegating? I think it reads as well and avoids having to check end positions. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Though the unconditional downcast casts always make me a little uncomfortable, there's precedent even in this class to unconditionally cast to public static boolean hasImplicitType(VariableTree tree, VisitorState state) {
JCVariableDecl varTree = (JCVariableDecl) tree;
return varTree.declaredUsingVar() || varTree.isImplicitlyTyped();
} Unfortunately this causes the existing
When I attach a debugger then I see that indeed I'll propose a new comment to document this observation. (Tested with Temurin-11.0.20.1+1 and Temurin-17.0.8.1+1.) There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Thanks for trying that out, and for the comment. |
||
} | ||
|
||
/** Returns {@code true} if the given tree has an explicit source code representation. */ | ||
public static boolean hasExplicitSource(Tree tree, VisitorState state) { | ||
return getStartPosition(tree) != Position.NOPOS && state.getEndPosition(tree) != Position.NOPOS; | ||
} | ||
|
||
/** Returns {@code true} if this symbol was declared in Kotlin source. */ | ||
|
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -26,7 +26,8 @@ | |
import static com.google.errorprone.matchers.Description.NO_MATCH; | ||
import static com.google.errorprone.util.ASTHelpers.getSymbol; | ||
import static com.google.errorprone.util.ASTHelpers.getType; | ||
import static com.google.errorprone.util.ASTHelpers.hasNoExplicitType; | ||
import static com.google.errorprone.util.ASTHelpers.hasExplicitSource; | ||
import static com.google.errorprone.util.ASTHelpers.hasImplicitType; | ||
import static com.sun.source.tree.Tree.Kind.METHOD; | ||
import static javax.lang.model.element.ElementKind.LOCAL_VARIABLE; | ||
|
||
|
@@ -86,6 +87,11 @@ public class VoidMissingNullable extends BugChecker | |
@Override | ||
public Description matchParameterizedType( | ||
ParameterizedTypeTree parameterizedTypeTree, VisitorState state) { | ||
if (!hasExplicitSource(parameterizedTypeTree, state)) { | ||
/* Implicit types cannot be annotated. */ | ||
return NO_MATCH; | ||
} | ||
Comment on lines
+90
to
+93
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. We could expand the comment like here, but I'm not sure that we want to make a similarly strong statement about inference of local parameterized types. |
||
|
||
if (beingConservative && state.errorProneOptions().isTestOnlyTarget()) { | ||
return NO_MATCH; | ||
} | ||
|
@@ -141,7 +147,7 @@ public Description matchVariable(VariableTree tree, VisitorState state) { | |
return NO_MATCH; | ||
} | ||
|
||
if (hasNoExplicitType(tree, state)) { | ||
if (hasImplicitType(tree, state)) { | ||
/* | ||
* In the case of `var`, a declaration-annotation @Nullable would be valid. But a type-use | ||
* @Nullable would not be. But more importantly, we expect that tools will infer the | ||
|
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 going to temporarily add
hasNoExplicitType
back, but make it deprecated and have it delegate tohasImplicitType
. We have some internal checks calling the old method and it's easier than fixing everything atomically, and it might also be helpful to other users to leave the old method around for a release or two.(I have started importing the change and can make that fix on my side, you don't need to update the PR.)