[ty] Validate type variable defaults don't reference later type parameters or type parameters out of scope by AlexWaygood · Pull Request #23623 · astral-sh/ruff (original) (raw)
and others added 6 commits
…variables
Type variable defaults can reference earlier type variables in the
parameter list (PEP 696), but not later ones. For example,
class C[T, U = T] is valid, but class C[S = T, T = int] is not
because S's default references T which is defined after S.
This adds a check in class body inference that walks PEP 695 type
parameter defaults and reports invalid-generic-class if any default
references a type variable that appears later in the parameter list.
https://claude.ai/code/session_01CmptNs5MMq5fsoQr7Ahqai
The existing check that type variable defaults don't reference later type
parameters only applied to PEP 695 generic contexts. This extends it to
legacy Generic[...] contexts as well, so that e.g.
class Foo(Generic[T2, T1]) where T2 = TypeVar("T2", default=T1)
correctly emits an error.
https://claude.ai/code/session_01CmptNs5MMq5fsoQr7Ahqai
…type parameter list
Previously, the check for invalid typevar default references only looked for typevars appearing later in the same type parameter list. This missed the case where a typevar's default references a typevar that isn't in the list at all.
For example, class Bad(Generic[Start2T, Stop2T, StepT]) where Start2T's
default is StopT (a different typevar not in the class's parameter list) was
not flagged.
The fix replaces contains_typevar (checking specific later typevars) with
find_typevar_not_in (finding any typevar not in the set of earlier typevars).
This catches both later-in-list and not-in-list cases.
https://claude.ai/code/session_01CmptNs5MMq5fsoQr7Ahqai
… out of scope
When the referenced type variable is totally out of scope (not in the class's type parameter list at all), we only show the secondary annotation for the typevar with the bad default, not the out-of-scope one.
https://claude.ai/code/session_01CmptNs5MMq5fsoQr7Ahqai
[ty] Validate type variable defaults don't reference later type parameters [ty] Validate type variable defaults don't reference later type parameters or type parameters out of scope
AlexWaygood pushed a commit that referenced this pull request
AlexWaygood pushed a commit that referenced this pull request
carljm added a commit that referenced this pull request
- main:
[ty] Move binary expression logic out of
builder.rs(#23649) [ty] Limit recursion depth when displaying self-referential function types (#23647) [ty] Move comparison logic out ofbuilder.rs(#23646) Avoid inserting redundantNoneelements in UP045 (#23459) [ty] Add more ParamSpec validation forP.argsandP.kwargs(#23640) [ty] Sync vendored typeshed stubs (#23642) [ty] Fix inference oft.__mro__iftis an instance oftype[Any](#23632) [ty] Detect inconsistent generic base class specializations (#23615) [ty] Validate type variable defaults don't reference later type parameters or type parameters out of scope (#23623) [ty] Ban nestedRequired/NotRequired, and ban them both outside ofTypedDictfields (#23627) [ty] Reject generic metaclasses parameterized by type variables (#23628) Update default Python version examples (#23605) fix binops with NewType of float and Unknown (#23620) [ty] Reject functions with PEP-695 type parameters that shadow type parameters from enclosing scopes (#23619) [ty] Reject ellipsis literals in odd places in type/annotation expressions (#23611) [ty] hash-consUseDefMapfields (#23283)
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.Learn more about bidirectional Unicode characters
[ Show hidden characters]({{ revealButtonHref }})