[Conformance][RFC] Distinguish "too broad" from "wrong" variance errors in protocol variance conformance test #2171
Description
The current protocol variance conformance test requires variance mismatch errors at the class definition line. I'd like to suggest distinguishing two cases and get feedback on whether this makes sense.
Case 1: Declared variance is too broad
When, for example, an invariant type var could be more specific, the error at the class definition makes sense and this is already what the tests are doing.
Case 2: Declared variance is wrong
For example, when a type var is declared covariant but used in an input position, the conformance test currently requires an error at the class definition and makes the error at the usage site optional. The usage site error is important because that's where the actual violation is and making it optional means a type checker could report only the class-definition error and never tell us which method is wrong. But if the usage-site error is required, having the class-definition error also required means two errors for the same problem.
RFC:
Would it make sense to swap these? making the usage site error required and the class-definition error optional? Pyright currently emits a warning at the class definition and an error at the usage site for these cases which seems to align with this approach.
The spec says "type checkers will warn if the inferred variance is different from the declared variance" but doesn't mandate where that warning appears. For case 2, the usage site seems more informative since it points to the exact method signature to fix.
Does this distinction make sense, or is there a reason to keep the class-definition error required for both cases?