-
Notifications
You must be signed in to change notification settings - Fork 39
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
Introduce CanonicalClassNameUsage
check
#881
Conversation
Looks good. All 15 mutations in this change were killed.
Mutation testing report by Pitest. Review any surviving mutants by inspecting the line comments under Files changed. |
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 🚀
Left one question.
|
||
@Override | ||
public Description matchMethodInvocation(MethodInvocationTree tree, VisitorState state) { | ||
if (!GET_NAME_INVOCATION.matches(tree, state) || !isPassedToCanonicalNameUsingType(state)) { |
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.
Acording to Class#getCanonicalName
docs, the method can return null for local, anonymous & hidden classes.
I wonder do we need to add a CanonicalNameIsNotNull
check here ?
But I guess the idea is that methods that accept canonical names are aware of the API...
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.
Oeh nice that you think about such edge cases 🚀 !
Interesting it will indeed not work if we rewrite new Object(){}.getClass().getName()
as it will return null
. However, it does not really make sense to write such code in one of the methods that we flag, which are specific methods from tech.picnic.errorprone
or com.google.errorprone
. So I think for now it's fine to not flag this 🤔.
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.
Nice catch @mohamedsamehsalah! In practice we're interested in matching .getName()
on class literals I see, so we can add an additional constraint for that; then the result will never be null
.
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.
Code looks nice! Good improvement 🚀!
public final class CanonicalClassNameUsage extends BugChecker | ||
implements MethodInvocationTreeMatcher { | ||
private static final long serialVersionUID = 1L; | ||
private static final Matcher<ExpressionTree> GET_NAME_INVOCATION = |
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.
For these situations we use both _INVOCATION
and _METHOD
. I feel INVOCATION
fits better here. Maybe we should apply this consistently 🤔.
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.
Indeed; I had the same feeling. Last I looked into this (won't do another pass now) there were more inconsistencies, so perhaps this is something to review in a separate PR.
2e67804
to
1fa3951
Compare
Looks good. All 15 mutations in this change were killed.
Mutation testing report by Pitest. Review any surviving mutants by inspecting the line comments under Files changed. |
1fa3951
to
2695c4d
Compare
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.
Tnx for the reviews @mohamedsamehsalah and @rickie! I rebased and added a commit.
public final class CanonicalClassNameUsage extends BugChecker | ||
implements MethodInvocationTreeMatcher { | ||
private static final long serialVersionUID = 1L; | ||
private static final Matcher<ExpressionTree> GET_NAME_INVOCATION = |
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.
Indeed; I had the same feeling. Last I looked into this (won't do another pass now) there were more inconsistencies, so perhaps this is something to review in a separate PR.
|
||
@Override | ||
public Description matchMethodInvocation(MethodInvocationTree tree, VisitorState state) { | ||
if (!GET_NAME_INVOCATION.matches(tree, state) || !isPassedToCanonicalNameUsingType(state)) { |
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.
Nice catch @mohamedsamehsalah! In practice we're interested in matching .getName()
on class literals I see, so we can add an additional constraint for that; then the result will never be null
.
Looks good. All 15 mutations in this change were killed.
Mutation testing report by Pitest. Review any surviving mutants by inspecting the line comments under Files changed. |
Error Prone checks deal with source code and type matchers, both of which generally involve canonical type names, rather than the strings produced by `Class#getName()`. This distinction is particularly relevant when dealing with nested types.
2695c4d
to
9307a2e
Compare
Quality Gate passedKudos, no new issues were introduced! 0 New issues |
Looks good. All 15 mutations in this change were killed.
Mutation testing report by Pitest. Review any surviving mutants by inspecting the line comments under Files changed. |
Suggested commit message: