ruff

9e80e5a3 - [ty] Support `type[…]` and `Type[…]` in implicit type aliases (#21421)

[ty] Support `type[…]` and `Type[…]` in implicit type aliases (#21421) ## Summary Support `type[…]` in implicit type aliases, for example: ```py SubclassOfInt = type[int] reveal_type(SubclassOfInt) # GenericAlias def _(subclass_of_int: SubclassOfInt): reveal_type(subclass_of_int) # type[int] ``` part of https://github.com/astral-sh/ty/issues/221 ## Typing conformance ```diff -specialtypes_type.py:138:5: error[type-assertion-failure] Argument does not have asserted type `type[Any]` -specialtypes_type.py:140:5: error[type-assertion-failure] Argument does not have asserted type `type[Any]` ``` Two new tests passing :heavy_check_mark: ```diff -specialtypes_type.py:146:1: error[unresolved-attribute] Object of type `GenericAlias` has no attribute `unknown` ``` An `TA4.unknown` attribute on a PEP 613 alias (`TA4: TypeAlias = type[Any]`) is being accessed, and the conformance suite expects this to be an error. Since we currently use the inferred type for these type aliases (and possibly in the future as well), we treat this as a direct access of the attribute on `type[Any]`, which falls back to an access on `Any` itself, which succeeds. :red_circle: ``` +specialtypes_type.py:152:16: error[invalid-type-form] `typing.TypeVar` is not a generic class +specialtypes_type.py:156:16: error[invalid-type-form] `typing.TypeVar` is not a generic class ``` New errors because we don't handle `T = TypeVar("T"); MyType = type[T]; MyType[T]` yet. Support for this is being tracked in https://github.com/astral-sh/ty/issues/221 :red_circle: ## Ecosystem impact Looks mostly good, a few known problems. ## Test Plan New Markdown tests