[red-knot] PEP 695 type aliases

[sharkdp]

Summary

Add support for (non-generic) type aliases. The main motivation behind this was to get rid of panics involving expressions in (generic) type aliases. But it turned out the best way to fix it was to implement (partial) support for type aliases.

type IntOrStr = int | str

reveal_type(IntOrStr)  # revealed: typing.TypeAliasType
reveal_type(IntOrStr.__name__)  # revealed: Literal["IntOrStr"]

x: IntOrStr = 1

reveal_type(x)  # revealed: Literal[1]

def f() -> None:
    reveal_type(x)  # revealed: int | str

Test Plan

• Updated corpus test allow list to reflect that we don't panic anymore.
• Added Markdown-based test for type aliases (type_alias.md)

[carljm]

Happy to do a VC call next week if anything remains unclear about how this is all supposed to work!

[github-actions]

ruff-ecosystem results

Linter (stable)

✅ ecosystem check detected no linter changes.

Linter (preview)

✅ ecosystem check detected no linter changes.

[carljm]

The updated type inference structure looks great!

[carljm]

This is interesting. I suspect it might go away if we stop trying to infer the type of .value() on a type alias anytime we encounter it. If not I'll want to take a closer look.

[sharkdp]

It happens for self-referential type aliases like type NestedInt = int | list[NestedInt]. We form a genuine cycle when inferring the annotation type on the RHS and look up the name NestedInt.