ruff/crates/ty_python_semantic
Carl Meyer 8b827c3c6c
[ty] rename BareTypeAliasType to ManualPEP695TypeAliasType (#20037)
## Summary

Rename `TypeAliasType::Bare` to `TypeAliasType::ManualPEP695`, and
`BareTypeAliasType` to `ManualPEP695TypeAliasType`.

Why?

Both existing variants of `TypeAliasType` are specific to features added
in PEP 695 (which introduced both the `type` statement and
`types.TypeAliasType`), so it doesn't make sense to name one with the
name `PEP695` and not the other.

A "bare" type alias, in my mind, is a legacy type alias like `IntOrStr =
int | str`, which is "bare" in that there is nothing at all
distinguishing it as a type alias. I will want to use the "bare" name
for this variant, in a future PR.

The renamed variant here describes a type alias created with `IntOrStr =
types.TypeAliasType("IntOrStr", int | str)`, which is not "bare", it's
just "manually" instantiated instead of using the `type` statement
syntax sugar. (This is useful when using the `typing_extensions`
backport of `TypeAliasType` on older Python versions.)

## Test Plan

Pure rename, existing tests pass.
2025-08-22 07:40:29 -07:00
..
resources [ty] Sync vendored typeshed stubs (#20031) 2025-08-21 21:32:48 +00:00
src [ty] rename BareTypeAliasType to ManualPEP695TypeAliasType (#20037) 2025-08-22 07:40:29 -07:00
tests [ty] Track open files in the server (#19264) 2025-07-18 19:33:35 +05:30
build.rs Rename Red Knot (#17820) 2025-05-03 19:49:15 +02:00
Cargo.toml [ty] Avoid overcounting shared memory usage (#19773) 2025-08-06 15:32:02 -04:00
mdtest.py Rename Red Knot (#17820) 2025-05-03 19:49:15 +02:00
mdtest.py.lock Rename Red Knot (#17820) 2025-05-03 19:49:15 +02:00