Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Require parameters in overrides to match those of the overridden method.
The default CF behavior is to allow for contravariance. JSpecify may eventually follow CF (jspecify/jspecify#49), and even if it doesn't, any given checker could choose to support it. I wouldn't have bothered to make this change except that I was having problems with the `Ordering.min`/`max` case: jspecify/jspecify@972fad0#diff-73db3d90f7545c1ed55a628fdf803a47b14f37bd08cb1eb0aedfa45b44bf1ddfR53 https://github.com/google/guava/blob/751d7c0d5f1fe3cbc067987e7d185763affa9ec7/guava/src/com/google/common/collect/ReverseOrdering.java#L54 I have not fully understood what's going wrong in that case. From the error message, I get the impression that CF is perhaps not "adapting the formal parameter types of N to the the type parameters of M" (JLS 8.4.2). Or rather, it does but only in the case of a _top-level_ type variable, meaning _not_ in the array-of-type-variable-usages case? https://github.com/typetools/checker-framework/blob/fd0abaa8b8fea775aaf71057d93d9415355b665e/framework/src/main/java/org/checkerframework/common/basetype/BaseTypeVisitor.java#L3883 (I forget whether the similar `Lib<E>` case worked, but I suspect so. Maybe that's covered by CF's contravariance and then by the specifics of how it compares type variables to one another?)
- Loading branch information