Avoid ambiguous imports with @UseImportPolicy(STATIC_IMPORT_ALWAYS)
#3584
Conversation
This is a workaround for the issue resolved by google/error-prone#3584. After application of this Refaster rule, any static imports of `java.util.Collections.reverseOrder` are obsolete. These can be removed by running Google Java Format or Error Prone's `RemoveUnusedImports` check. Where possible, subsequent application of the `StaticImport` checker will statically import `java.util.Comparator.reverseOrder`.
This is a workaround for the issue resolved by google/error-prone#3584. After application of this Refaster rule, any static imports of `java.util.Collections.reverseOrder` are obsolete. These can be removed by running Google Java Format or Error Prone's `RemoveUnusedImports` check. Where possible, subsequent application of the `StaticImport` checker will statically import `java.util.Comparator.reverseOrder`.
…#397) This is a workaround for the issue resolved by google/error-prone#3584. After application of this Refaster rule, any static imports of `java.util.Collections.reverseOrder` are obsolete. These can be removed by running Google Java Format or Error Prone's `RemoveUnusedImports` check. Where possible, subsequent application of the `StaticImport` check will statically import `java.util.Comparator.reverseOrder`.
Stephan202
force-pushed
the
bugfix/refaster-static-import-clash
branch
from
d548298
to
6086de5
Compare
These changes prevent Refaster rules from introducing a static import that
conflicts with an existing static import. Without these changes the new test
case fails with the following error:
```
com/google/errorprone/refaster/testdata/StaticImportClashTemplate.java:27: error: reference to reverseOrder is ambiguous
return reverseOrder();
^
both method <T>reverseOrder() in java.util.Comparator and method <T>reverseOrder() in java.util.Collections match
```
Stephan202
force-pushed
the
bugfix/refaster-static-import-clash
branch
from
6086de5
to
8185405
Compare
|
Rebased and resolved conflicts. |
|
We still encounter this problem every now and then. Could you take a look at this @cushon? |
|
Sorry for the delay here. I tried importing this, and ran into some issues with templates we have for cleanups related to https://github.com/google/truth. Truth deliberately declares overloads of In general I'm not sure there's a good way for refaster to know if a particular static import is going to be ambiguous or not, and I'd like to keep the Do you have any ideas for dealing with that case? |
|
Wow... I didn't even know this was supported. 🤯 It might be possible to resolve the conflicting symbol and check whether it'd be ambiguous. But that does sound like the kind of rabbit hole for which one should set aside a few hours. I'll make a note and try to get back to this. |
There was a problem hiding this comment.
I think this is blocked on #3584 (comment)
I'm open to ideas about how to solve this. If it isn't possible to make the existing policy smart enough to handle that case, we could always consider adding yet another @UseImportPolicy or something
|
Tnx for the ping on this one. Can't say exactly when I'll have time for a closer look, but I'll try to bump it on the TODO list 👍 |
…e}` Refaster rules This is a workaround for google/error-prone#3584. While there, drop an unused method from `JUnitToAssertJRules`.
…e}` Refaster rules This is a workaround for google/error-prone#3584. While there, drop an unused method from `JUnitToAssertJRules`.
…e}` Refaster rules This is a workaround for google/error-prone#3584. While there, drop an unused method from `JUnitToAssertJRules`.
…e}` Refaster rules (#939) This is a workaround for google/error-prone#3584. While there, drop an unused method from `JUnitToAssertJRules`.
These changes prevent Refaster rules from introducing a static import that
conflicts with an existing static import. Without these changes the new test
case fails with the following error: