[ty] defer inference of legacy TypeVar bound/constraints/defaults

crates/ty_ide/src/goto_type_definition.rs

@@ -308,26 +308,8 @@ mod tests {
             "#,
         );
 
-        assert_snapshot!(test.goto_type_definition(), @r#"
-        info[goto-type-definition]: Type definition
-         --> main.py:4:1
-          |
-        2 | from typing_extensions import TypeAliasType
-        3 |
-        4 | Alias = TypeAliasType("Alias", tuple[int, int])
-          | ^^^^^
-        5 |
-        6 | Alias
-          |
-        info: Source
-         --> main.py:6:1
-          |
-        4 | Alias = TypeAliasType("Alias", tuple[int, int])
-        5 |
-        6 | Alias
-          | ^^^^^
-          |
-        "#);
+        // TODO: This should jump to the definition of `Alias` above.
+        assert_snapshot!(test.goto_type_definition(), @"No type definitions found");
     }
 
     #[test]

crates/ty_python_semantic/resources/mdtest/diagnostics/legacy_typevars.md

@@ -0,0 +1,139 @@
+# Legacy typevar creation diagnostics
+
+The full tests for these features are in `generics/legacy/variables.md`.
+
+<!-- snapshot-diagnostics -->
+
+## Must have a name
+
+```py
+from typing import TypeVar
+
+# error: [invalid-legacy-type-variable]
+T = TypeVar()
+```
+
+## Name can't be given more than once
+
+```py
+from typing import TypeVar
+
+# error: [invalid-legacy-type-variable]
+T = TypeVar("T", name="T")
+```
+
+## Must be directly assigned to a variable
+
+> A `TypeVar()` expression must always directly be assigned to a variable (it should not be used as
+> part of a larger expression).
+
+```py
+from typing import TypeVar
+
+T = TypeVar("T")
+# error: [invalid-legacy-type-variable]
+U: TypeVar = TypeVar("U")
+
+# error: [invalid-legacy-type-variable]
+tuple_with_typevar = ("foo", TypeVar("W"))
+```
+
+## `TypeVar` parameter must match variable name
+
+> The argument to `TypeVar()` must be a string equal to the variable name to which it is assigned.
+
+```py
+from typing import TypeVar
+
+# error: [invalid-legacy-type-variable]
+T = TypeVar("Q")
+```
+
+## No variadic arguments
+
+```py
+from typing import TypeVar
+
+types = (int, str)
+
+# error: [invalid-legacy-type-variable]
+T = TypeVar("T", *types)
+
+# error: [invalid-legacy-type-variable]
+S = TypeVar("S", **{"bound": int})
+```
+
+## Cannot have only one constraint
+
+> `TypeVar` supports constraining parametric types to a fixed set of possible types...There should
+> be at least two constraints, if any; specifying a single constraint is disallowed.
+
+```py
+from typing import TypeVar
+
+# error: [invalid-legacy-type-variable]
+T = TypeVar("T", int)
+```
+
+## Cannot have both bound and constraint
+
+```py
+from typing import TypeVar
+
+# error: [invalid-legacy-type-variable]
+T = TypeVar("T", int, str, bound=bytes)
+```
+
+## Cannot be both covariant and contravariant
+
+> To facilitate the declaration of container types where covariant or contravariant type checking is
+> acceptable, type variables accept keyword arguments `covariant=True` or `contravariant=True`. At
+> most one of these may be passed.
+
+```py
+from typing import TypeVar
+
+# error: [invalid-legacy-type-variable]
+T = TypeVar("T", covariant=True, contravariant=True)
+```
+
+## Boolean parameters must be unambiguous
+
+```py
+from typing_extensions import TypeVar
+
+def cond() -> bool:
+    return True
+
+# error: [invalid-legacy-type-variable]
+T = TypeVar("T", covariant=cond())
+
+# error: [invalid-legacy-type-variable]
+U = TypeVar("U", contravariant=cond())
+
+# error: [invalid-legacy-type-variable]
+V = TypeVar("V", infer_variance=cond())
+```
+
+## Invalid keyword arguments
+
+```py
+from typing import TypeVar
+
+# error: [invalid-legacy-type-variable]
+T = TypeVar("T", invalid_keyword=True)
+```
+
+## Invalid feature for this Python version
+
+```toml
+[environment]
+python-version = "3.10"
+```
+
+```py
+from typing import TypeVar
+
+# error: [invalid-legacy-type-variable]
+T = TypeVar("T", default=int)
+```

crates/ty_python_semantic/resources/mdtest/generics/legacy/classes.md

@@ -108,7 +108,7 @@ reveal_type(generic_context(ExplicitInheritedGenericPartiallySpecializedExtraTyp
 The type parameter can be specified explicitly:
 
 ```py
-from typing import Generic, Literal, TypeVar
+from typing_extensions import Generic, Literal, TypeVar
 
 T = TypeVar("T")
 
@@ -195,7 +195,7 @@ reveal_type(WithDefault[str]())  # revealed: WithDefault[str, int]
 We can infer the type parameter from a type context:
 
 ```py
-from typing import Generic, TypeVar
+from typing_extensions import Generic, TypeVar
 
 T = TypeVar("T")
 
@@ -240,7 +240,7 @@ consistent with each other.
 ### `__new__` only
 
 ```py
-from typing import Generic, TypeVar
+from typing_extensions import Generic, TypeVar
 
 T = TypeVar("T")
 
@@ -257,7 +257,7 @@ wrong_innards: C[int] = C("five")
 ### `__init__` only
 
 ```py
-from typing import Generic, TypeVar
+from typing_extensions import Generic, TypeVar
 
 T = TypeVar("T")
 
@@ -273,7 +273,7 @@ wrong_innards: C[int] = C("five")
 ### Identical `__new__` and `__init__` signatures
 
 ```py
-from typing import Generic, TypeVar
+from typing_extensions import Generic, TypeVar
 
 T = TypeVar("T")
 
@@ -292,7 +292,7 @@ wrong_innards: C[int] = C("five")
 ### Compatible `__new__` and `__init__` signatures
 
 ```py
-from typing import Generic, TypeVar
+from typing_extensions import Generic, TypeVar
 
 T = TypeVar("T")
 
@@ -325,7 +325,7 @@ If either method comes from a generic base class, we don't currently use its inf
 to specialize the class.
 
 ```py
-from typing import Generic, TypeVar
+from typing_extensions import Generic, TypeVar
 
 T = TypeVar("T")
 U = TypeVar("U")
@@ -344,7 +344,7 @@ reveal_type(D(1))  # revealed: D[int]
 ### Generic class inherits `__init__` from generic base class
 
 ```py
-from typing import Generic, TypeVar
+from typing_extensions import Generic, TypeVar
 
 T = TypeVar("T")
 U = TypeVar("U")
@@ -364,7 +364,7 @@ reveal_type(D(1, "str"))  # revealed: D[int, str]
 This is a specific example of the above, since it was reported specifically by a user.
 
 ```py
-from typing import Generic, TypeVar
+from typing_extensions import Generic, TypeVar
 
 T = TypeVar("T")
 U = TypeVar("U")
@@ -382,7 +382,7 @@ for `tuple`, so we use a different mechanism to make sure it has the right inher
 context. But from the user's point of view, this is another example of the above.)
 
 ```py
-from typing import Generic, TypeVar
+from typing_extensions import Generic, TypeVar
 
 T = TypeVar("T")
 U = TypeVar("U")
@@ -403,7 +403,7 @@ python-version = "3.11"
 ```
 
 ```py
-from typing import TypeVar, Sequence, Never
+from typing_extensions import TypeVar, Sequence, Never
 
 T = TypeVar("T")
 
@@ -421,7 +421,7 @@ def func8(t1: tuple[complex, list[int]], t2: tuple[int, *tuple[str, ...]], t3: t
 ### `__init__` is itself generic
 
 ```py
-from typing import Generic, TypeVar
+from typing_extensions import Generic, TypeVar
 
 S = TypeVar("S")
 T = TypeVar("T")
@@ -440,7 +440,7 @@ wrong_innards: C[int] = C("five", 1)
 ### Some `__init__` overloads only apply to certain specializations
 
 ```py
-from typing import overload, Generic, TypeVar
+from typing_extensions import overload, Generic, TypeVar
 
 T = TypeVar("T")
 
@@ -480,7 +480,7 @@ C[None](12)
 
 ```py
 from dataclasses import dataclass
-from typing import Generic, TypeVar
+from typing_extensions import Generic, TypeVar
 
 T = TypeVar("T")
 
@@ -494,7 +494,7 @@ reveal_type(A(x=1))  # revealed: A[int]
 ### Class typevar has another typevar as a default
 
 ```py
-from typing import Generic, TypeVar
+from typing_extensions import Generic, TypeVar
 
 T = TypeVar("T")
 U = TypeVar("U", default=T)
@@ -515,7 +515,7 @@ When a generic subclass fills its superclass's type parameter with one of its ow
 propagate through:
 
 ```py
-from typing import Generic, TypeVar
+from typing_extensions import Generic, TypeVar
 
 T = TypeVar("T")
 U = TypeVar("U")
@@ -549,7 +549,7 @@ scope for the method.
 
 ```py
 from ty_extensions import generic_context
-from typing import Generic, TypeVar
+from typing_extensions import Generic, TypeVar
 
 T = TypeVar("T")
 U = TypeVar("U")
@@ -581,7 +581,7 @@ In a specialized generic alias, the specialization is applied to the attributes
 class.
 
 ```py
-from typing import Generic, TypeVar, Protocol
+from typing_extensions import Generic, TypeVar, Protocol
 
 T = TypeVar("T")
 U = TypeVar("U")
@@ -639,7 +639,7 @@ reveal_type(d.method3().x)  # revealed: int
 When a method is overloaded, the specialization is applied to all overloads.
 
 ```py
-from typing import overload, Generic, TypeVar
+from typing_extensions import overload, Generic, TypeVar
 
 S = TypeVar("S")
 
@@ -667,7 +667,7 @@ A class can use itself as the type parameter of one of its superclasses. (This i
 Here, `Sub` is not a generic class, since it fills its superclass's type parameter (with itself).
 
 ```pyi
-from typing import Generic, TypeVar
+from typing_extensions import Generic, TypeVar
 
 T = TypeVar("T")
 
@@ -682,7 +682,7 @@ reveal_type(Sub)  # revealed: <class 'Sub'>
 A similar case can work in a non-stub file, if forward references are stringified:
 
 ```py
-from typing import Generic, TypeVar
+from typing_extensions import Generic, TypeVar
 
 T = TypeVar("T")
 
@@ -697,7 +697,7 @@ reveal_type(Sub)  # revealed: <class 'Sub'>
 In a non-stub file, without stringified forward references, this raises a `NameError`:
 
 ```py
-from typing import Generic, TypeVar
+from typing_extensions import Generic, TypeVar
 
 T = TypeVar("T")
 
@@ -710,7 +710,7 @@ class Sub(Base[Sub]): ...
 ### Cyclic inheritance as a generic parameter
 
 ```pyi
-from typing import Generic, TypeVar
+from typing_extensions import Generic, TypeVar
 
 T = TypeVar("T")
 
@@ -722,7 +722,7 @@ class Derived(list[Derived[T]], Generic[T]): ...
 Inheritance that would result in a cyclic MRO is detected as an error.
 
 ```py
-from typing import Generic, TypeVar
+from typing_extensions import Generic, TypeVar
 
 T = TypeVar("T")