Skip to content
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

Merged
merged 6 commits into from
Apr 12, 2022

Conversation

Badbond
Copy link
Member

@Badbond Badbond commented Mar 15, 2022

Adds a candidate to StaticImportCheck to statically import ImportPolicy usages. Causes @UseImportPolicy(ImportPolicy.STATIC_IMPORT_ALWAYS) to be changed to @UseImportPolicy(STATIC_IMPORT_ALWAYS).

Self applied to this repository using:

  1. 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;'
  2. 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)/'
  3. IntelliJ reformatting to rearrange the imports and remove unused ones.

@Badbond Badbond requested review from Stephan202 and rickie March 15, 2022 15:49
@@ -2213,7 +2213,7 @@ void after(Predicate<T> predicate, T object) {
// }
//
// @AfterTemplate
// @UseImportPolicy(ImportPolicy.STATIC_IMPORT_ALWAYS)
// @UseImportPolicy(STATIC_IMPORT_ALWAYS)
Copy link
Member Author

@Badbond Badbond Mar 15, 2022

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 😜

@rickie rickie requested a review from mussatto March 17, 2022 08:23
Copy link
Member

@rickie rickie left a 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)",
Copy link
Member

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.

Copy link
Member Author

@Badbond Badbond Mar 17, 2022

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)",
Copy link
Member

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.

Copy link
Member Author

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.

Copy link
Member

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.

Copy link
Member Author

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.

@Badbond Badbond requested a review from rickie March 18, 2022 08:56
Copy link
Member

@rickie rickie left a 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`

Copy link
Contributor

@mussatto mussatto left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM :)

@Stephan202 Stephan202 force-pushed the pdsoels/static-import-policies branch from 3cf1a2c to fa08ac3 Compare April 10, 2022 11:26
Copy link
Member

@Stephan202 Stephan202 left a 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)

Comment on lines 103 to 106
" // BUG: Diagnostic contains:",
" @UseImportPolicy(ImportPolicy.IMPORT_TOP_LEVEL)",
" @AfterTemplate",
" void m2() {}",
Copy link
Member

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 :)

Suggested change
" // BUG: Diagnostic contains:",
" @UseImportPolicy(ImportPolicy.IMPORT_TOP_LEVEL)",
" @AfterTemplate",
" void m2() {}",
" // BUG: Diagnostic contains:",
" @UseImportPolicy(ImportPolicy.IMPORT_TOP_LEVEL)",
" void refasterAfterTemplate() {}",

Copy link
Member

@rickie rickie Apr 11, 2022

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?

Copy link
Member

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.

Copy link
Member

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 👍🏻 :).

@rickie rickie force-pushed the pdsoels/static-import-policies branch from fa08ac3 to d4b46a0 Compare April 11, 2022 08:27
@rickie
Copy link
Member

rickie commented Apr 11, 2022

Rebased.

@rickie
Copy link
Member

rickie commented Apr 12, 2022

Changes LGTM, WDYT @Badbond ? :)

@Badbond
Copy link
Member Author

Badbond commented Apr 12, 2022

LGTM as well 🚀

@Stephan202 Stephan202 merged commit 9192245 into master Apr 12, 2022
@Stephan202 Stephan202 deleted the pdsoels/static-import-policies branch April 12, 2022 08:36
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

Successfully merging this pull request may close these issues.

4 participants