ruff

192c37d5 - [ty] tighten up handling of subscripts in type expressions (#21503)

[ty] tighten up handling of subscripts in type expressions (#21503) ## Summary Get rid of the catch-all todo type from subscripting a base type we haven't implemented handling for yet in a type expression, and turn it into a diagnostic instead. Handle a few more cases explicitly, to avoid false positives from the above change: 1. Subscripting any dynamic type (not just a todo type) in a type expression should just result in that same dynamic type. This is important for gradual guarantee, and matches other type checkers. 2. Subscripting a generic alias may be an error or not, depending whether the specialization itself contains typevars. Don't try to handle this yet (it should be handled in a later PR for specializing generic non-PEP695 type aliases), just use a dedicated todo type for it. 3. Add a temporary todo branch to avoid false positives from string PEP 613 type aliases. This can be removed in the next PR, with PEP 613 type alias support. ## Test Plan Adjusted mdtests, ecosystem. All new diagnostics in conformance suite are supposed to be diagnostics, so this PR is a strict improvement there. New diagnostics in the ecosystem are surfacing cases where we already don't understand an annotation, but now we emit a diagnostic about it. They are mostly intentional choices. Analysis of particular cases: * `attrs`, `bokeh`, `django-stubs`, `dulwich`, `ibis`, `kornia`, `mitmproxy`, `mongo-python-driver`, `mypy`, `pandas`, `poetry`, `prefect`, `pydantic`, `pytest`, `scrapy`, `trio`, `werkzeug`, and `xarray` are all cases where under `from __future__ import annotations` or Python 3.14 deferred-annotations semantics, we follow normal name-scoping rules, whereas some other type checkers prefer global names over local names. This means we don't like it if e.g. you have a class with a method or attribute named `type` or `tuple`, and you also try to use `type` or `tuple` in method/attribute annotations of that class. This PR isn't changing those semantics, just revealing them in more cases where previously we just silently fell back to `Unknown`. I think failing with a diagnostic (so authors can alias names as needed to avoid relying on scoping rules that differ between type checkers) is better than failing silently here. * `beartype` assumes we support `TypeForm` (because it only supports mypy and pyright, it uses `if MYPY:` to hide the `TypeForm` from mypy, and pyright supports `TypeForm`), and we don't yet. * `graphql-core` likes to use a `try: ... except ImportError: ...` pattern for importing special forms from `typing` with fallback to `typing_extensions`, instead of using `sys.version_info` checks. We don't handle this well when type checking under an older Python version (where the import from `typing` is not found); we see the imported name as of type e.g. `Unknown | SpecialFormType(...)`, and because of the union with `Unknown` we fail to handle it as the special form type. Mypy and pyright also don't seem to support this pattern. They don't complain about subscripting such special forms, but they do silently fail to treat them as the desired special form. Again here, if we are going to fail I'd rather fail with a diagnostic rather than silently. * `ibis` is [trying to use](https://github.com/ibis-project/ibis/blob/main/ibis/common/collections.py#L372) `frozendict: type[FrozenDict]` as a way to create a "type alias" to `FrozenDict`, but this is wrong: that means `frozendict: type[FrozenDict[Any, Any]]`. * `mypy` has some errors due to the fact that type-checking `typing.pyi` itself (without knowing that it's the real `typing.pyi`) doesn't work very well. * `mypy-protobuf` imports some types from the protobufs library that end up unioned with `Unknown` for some reason, and so we don't allow explicit-specialization of them. Depending on the reason they end up unioned with `Unknown`, we might want to better support this? But it's orthogonal to this PR -- we aren't failing any worse here, just alerting the author that we didn't understand their annotation. * `pwndbg` has unresolved references due to star-importing from a dependency that isn't installed, and uses un-imported names like `Dict` in annotation expressions. Some of the unresolved references were hidden by https://github.com/astral-sh/ruff/blob/main/crates/ty_python_semantic/src/types/infer/builder.rs#L7223-L7228 when some annotations previously resolved to a Todo type that no longer do.