Avoid ambiguous imports with `@UseImportPolicy(STATIC_IMPORT_ALWAYS)`

[Stephan202]

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]

Rebased and resolved conflicts.

[rickie]

We still encounter this problem every now and then. Could you take a look at this @cushon?

[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 assertThat in different classes, with the expectation that they will all get static-imported and the most specific one will be selected, e.g.:

import static com.google.common.truth.Truth.assertThat;
import static com.google.common.truth.Truth8.assertThat;

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 assertThat templates.

Do you have any ideas for dealing with that case?

[Stephan202]

Wow... I didn't even know this was supported. :exploding_head:

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.

[Stephan202]

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 :+1:

[Stephan202]

(Reopening because I see that GitHub closed this PR base on imperfect heuritics. That said, this isn't at the top of my TODO list at the moment.)