Extend `TypeParameterQualifier` to cover method references (`T::foo`). I could see an argument that one of the cases newly covered by this CL, `T::instanceMethod`, is less bad than the other, `T::staticMethod` (which I see as as bad as the already covered cases of `T.staticMethod()` and `T.Type`): At least instance-method dispatch depends on the actual runtime type. Still, that's different than depending on the _compile-time_ type argument. Plus, it's not as if javac will do overload resolution based on the compile-time type argument; it always uses the bound. That seems like more than enough reason to ban `T::instanceMethod`, too, especially when the resulting rule is easy to explain: Don't use a type variable as a qualifier ever. (I notice that Kotlin is [not having any of it](https://pl.kotl.in/KyaHuhH5n).) PiperOrigin-RevId: 908818269
Error Prone is a static analysis tool for Java that catches common programming mistakes at compile-time.
public class ShortSet { public static void main (String[] args) { Set<Short> s = new HashSet<>(); for (short i = 0; i < 100; i++) { s.add(i); s.remove(i - 1); } System.out.println(s.size()); } }
error: [CollectionIncompatibleType] Argument 'i - 1' should not be passed to this method;
its type int is not compatible with its collection's type argument Short
s.remove(i - 1);
^
(see https://errorprone.info/bugpattern/CollectionIncompatibleType)
1 error
Our documentation is at errorprone.info.
Error Prone works with Bazel, Maven, Ant, and Gradle. See our installation instructions for details.
Developing and building Error Prone is documented on the wiki.