Fix problem with np.array related to type[T]

Author: sharkdp

crates/ty_python_semantic/resources/mdtest/implicit_type_aliases.md

@@ -500,14 +500,27 @@ def _(
 A generic implicit type alias can also be used in another generic implicit type alias:
 
 ```py
+from typing_extensions import Any
+
+B = TypeVar("B", bound=int)
+
 MyOtherList = MyList[T]
+MyOtherType = MyType[T]
+TypeOrList = MyType[B] | MyList[B]
 
 reveal_type(MyOtherList)  # revealed: <class 'list[T@MyOtherList]'>
+reveal_type(MyOtherType)  # revealed: GenericAlias
+reveal_type(TypeOrList)  # revealed: types.UnionType
 
 def _(
     list_of_ints: MyOtherList[int],
+    subclass_of_int: MyOtherType[int],
+    type_or_list: TypeOrList[Any],
 ):
     reveal_type(list_of_ints)  # revealed: list[int]
+    reveal_type(subclass_of_int)  # revealed: type[int]
+    # TODO: Should be `type[Any] | list[Any]`
+    reveal_type(type_or_list)  # revealed: @Todo(type[T]) | list[Any]
 ```
 
 If a generic implicit type alias is used unspecialized in a type expression, we treat it as an
@@ -1456,3 +1469,14 @@ def _(
     reveal_type(recursive_dict3)  # revealed: dict[Divergent, int]
     reveal_type(recursive_dict4)  # revealed: dict[Divergent, int]
 ```
+
+### Self-referential generic implicit type aliases
+
+<!-- expect-panic: execute: too many cycle iterations -->
+
+```py
+from typing import TypeVar
+
+T = TypeVar("T")
+NestedDict = dict[str, "NestedDict[T] | T"]
+```

crates/ty_python_semantic/src/types.rs

@@ -6799,7 +6799,7 @@ impl<'db> Type<'db> {
                 }
                 KnownInstanceType::Literal(ty) => Ok(ty.inner(db)),
                 KnownInstanceType::Annotated(ty) => Ok(ty.inner(db)),
-                KnownInstanceType::TypeGenericAlias(ty) => {
+                KnownInstanceType::TypeGenericAlias(instance) => {
                     // When `type[…]` appears in a value position (e.g. in an implicit type alias),
                     // we infer its argument as a type expression. This ensures that we can emit
                     // diagnostics for invalid type expressions, and more importantly, that we can
@@ -6808,7 +6808,7 @@ impl<'db> Type<'db> {
                     // (`int` -> instance of `int` -> subclass of `int`) can be lossy, but it is
                     // okay for all valid arguments to `type[…]`.
 
-                    Ok(ty.inner(db).to_meta_type(db))
+                    Ok(instance.inner(db).to_meta_type(db))
                 }
                 KnownInstanceType::Callable(instance) => {
                     Ok(Type::Callable(instance.callable_type(db)))
@@ -7046,16 +7046,8 @@ impl<'db> Type<'db> {
             }
             Type::Callable(_) | Type::DataclassTransformer(_) => KnownClass::Type.to_instance(db),
             Type::ModuleLiteral(_) => KnownClass::ModuleType.to_class_literal(db),
-            Type::TypeVar(bound_typevar) => {
-                match bound_typevar.typevar(db).bound_or_constraints(db) {
-                    None => KnownClass::Type.to_instance(db),
-                    Some(TypeVarBoundOrConstraints::UpperBound(bound)) => bound.to_meta_type(db),
-                    Some(TypeVarBoundOrConstraints::Constraints(constraints)) => {
-                        // TODO: If we add a proper `OneOf` connector, we should use that here instead
-                        // of union. (Using a union here doesn't break anything, but it is imprecise.)
-                        constraints.map(db, |constraint| constraint.to_meta_type(db))
-                    }
-                }
+            Type::TypeVar(_) => {
+                todo_type!("type[T]")
             }
 
             Type::ClassLiteral(class) => class.metaclass(db),