-
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
StaticImportCheck
use static imports for ImportPolicy
usages
#45
Conversation
@@ -2213,7 +2213,7 @@ void after(Predicate<T> predicate, T object) { | |||
// } | |||
// | |||
// @AfterTemplate | |||
// @UseImportPolicy(ImportPolicy.STATIC_IMPORT_ALWAYS) | |||
// @UseImportPolicy(STATIC_IMPORT_ALWAYS) |
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.
Would be cool if EP could do this as well @rickie 😜
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.
Good idea to add this one to StaticImport
. Left some suggestions 😄.
@@ -97,6 +99,8 @@ void identification() { | |||
" Optional.empty();", | |||
" }", | |||
"", | |||
" // BUG: Diagnostic contains:", | |||
" @UseImportPolicy(ImportPolicy.STATIC_IMPORT_ALWAYS)", |
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 feel that we are now mixing two test cases in one thing. The toImmutableMultiset()
is required for code above:
" // Not flagged because we define #toImmutableMultiset below.",
Therefore I'd suggest to leave the method as is and not annotate it.
We could make a new method in this test and annotate that method with @UseImportPolicy
.
I'll push a suggestion in a sec.
Normally UseImportPolicy
should only be used in the context of Refaster. Here we can see that (when running Refaster) it is required to have @AfterTemplate
present when we use UseImportPolicy
. Now in this case it is, strictly speaking, not a problem (because RequiredAnnotation
is only checked on Refaster templates at runtime), nevertheless it seems better to add the @AfterTemplate
here as well.
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.
You are right, I was making it myself a bit too easy here (also for below) 😅 Makes sense to make the test case best represent actual usage 👍 Thanks for committing the suggestion!
@@ -122,6 +128,7 @@ void replacement() { | |||
"import org.springframework.http.MediaType;", | |||
"", | |||
"class A {", | |||
" @UseImportPolicy(ImportPolicy.STATIC_IMPORT_ALWAYS)", |
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.
A few questions / suggestions;
I'm not a fan of adding this method on the big method that contains many test cases. It feels like we are "mixing up" things.
Also, especially for people that do not know the STATIC_IMPORT_ALWAYS
, it could be quite confusing to see this annotation here on a class where we are testing static imports.
Not 100% sure about whether this is an improvement, but we could decide to replace STATIC_IMPORT_ALWAYS
by a different ImportPolicy
(like IMPORT_TOP_LEVEL
) to prevent possible confusion. WDYT?
As explained in the other comment, only using @UseImportPolicy
is, strictly speaking, not valid. It would make sense to add @AfterTemplate
.
Lastly, I have some doubts about adding tests for ImportPolicy
in the replacement()
test. Again, because of the fact that we only should use this in the case of Refaster templates. Therefore it feels a bit like this test case doesn't really belong here. Perhaps, for this one case, we could decide that testing this in identification()
is "enough". Another argument in favor of this could be that not all cases from identification
are also in replacement
and the other way around.
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.
Lastly, I have some doubts about adding tests for ImportPolicy in the replacement() test. Again, because of the fact that we only should use this in the case of Refaster templates. Therefore it feels a bit like this test case doesn't really belong here. Perhaps, for this one case, we could decide that testing this in identification() is "enough". Another argument in favor of this could be that not all cases from identification are also in replacement and the other way around.
Not completely following you there, as there are also existing tests in replacement()
for static imports e.g. for Arguments.arguments
and Objects.requireNonNull
. Therefore, I did it for consistency and full test coverage. But I can imagine that we don't want to test every static import case this way. Would be good to have at least one static import replacement test-case for a static import on an annotation, however (did not check whether already exists). Otherwise, I'm also okay with removing this one.
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.
Therefore, I did it for consistency and full test coverage.
Yes, in most cases we add tests in both methods, so normally when introducing a static import candidate, it would indeed make total sense, so I fully understand why it is in the PR 😄. For this case, because it is a special Refaster thingy, I think we could approach a bit different than normally.
did not check whether already exists
There exists one, see here.
Not completely following you there
Did the extra explanation help? 😄, let me know, happy to discuss.
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.
With the reasoning that this is implicitly tested by self-check in this PR, I agree that we can remove the replacement()
testcase. Also used a different import in identification()
as suggested as STATIC_IMPORT_ALWAYS
could cause confusion in a StaticImportCheckTest
due to equal terminology.
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 improvement 💪🏻 .
Suggested commit message:
Require static import of `com.google.errorprone.refaster.ImportPolicy`
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 :)
3cf1a2c
to
fa08ac3
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.
Rebased and added a tiny commit. Tweaked suggested commit message:
Require static import of `com.google.errorprone.refaster.ImportPolicy` members (#45)
" // BUG: Diagnostic contains:", | ||
" @UseImportPolicy(ImportPolicy.IMPORT_TOP_LEVEL)", | ||
" @AfterTemplate", | ||
" void m2() {}", |
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.
Since it's "fake" anyway, we can just explain the context by giving the method a better name :)
" // BUG: Diagnostic contains:", | |
" @UseImportPolicy(ImportPolicy.IMPORT_TOP_LEVEL)", | |
" @AfterTemplate", | |
" void m2() {}", | |
" // BUG: Diagnostic contains:", | |
" @UseImportPolicy(ImportPolicy.IMPORT_TOP_LEVEL)", | |
" void refasterAfterTemplate() {}", |
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.
Why not try to be close to the "real deal" as discussed here?
We try to make examples realistic right?
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.
How realistic is realistic enough? See for example m2
and m3
in replacement
, which use @DateTimeFormat
on methods without any other annotations that would make Spring actually invoke it.
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.
Ah I see, thanks for the explanation, current state is 👍🏻 :).
fa08ac3
to
d4b46a0
Compare
Rebased. |
Changes LGTM, WDYT @Badbond ? :) |
LGTM as well 🚀 |
Adds a candidate to
StaticImportCheck
to statically importImportPolicy
usages. Causes@UseImportPolicy(ImportPolicy.STATIC_IMPORT_ALWAYS)
to be changed to@UseImportPolicy(STATIC_IMPORT_ALWAYS)
.Self applied to this repository using:
git grep 'ImportPolicy.STATIC_IMPORT_ALWAYS' | cut -d ":" -f 1 | xargs -n1 | sort -u | xargs sed -i '2i import static com.google.errorprone.refaster.ImportPolicy.STATIC_IMPORT_ALWAYS;'
git grep 'ImportPolicy.STATIC_IMPORT_ALWAYS' | cut -d ":" -f 1 | xargs -n1 | sort -u | xargs sed -i 's/@UseImportPolicy(ImportPolicy.STATIC_IMPORT_ALWAYS)/@UseImportPolicy(STATIC_IMPORT_ALWAYS)/'