Carl Meyer 17dc2e4d80 [ty] don't assume that deferred type inference means deferred name resolution (#20160) ... ## Summary We have the ability to defer type inference of some parts of definitions, so as to allow us to create a type that may need to be recursively referenced in those other parts of the definition. We also have the ability to do type inference in a context where all name resolution should be deferred (that is, names should be looked up from all-reachable-definitions rather than from the location of use.) This is used for all annotations in stubs, or if `from __future__ import annotations` is active. Previous to this PR, these two concepts were linked: deferred-inference always implied deferred-name-resolution, though we also supported deferred-name-resolution without deferred-inference, via `DeferredExpressionState`. For the upcoming `typing.TypeAlias` support, I will defer inference of the entire RHS of the alias (so as to support cycles), but that doesn't imply deferred name resolution; at runtime, the RHS of a name annotated as `typing.TypeAlias` is executed eagerly. So this PR fully de-couples the two concepts, instead explicitly setting the `DeferredExpressionState` in those cases where we should defer name resolution. It also fixes a long-standing related bug, where we were deferring name resolution of all names in class bases, if any of the class bases contained a stringified annotation. ## Test Plan Added test that failed before this PR.		2025-08-29 16:19:45 -07:00
..
resources	[ty] don't assume that deferred type inference means deferred name resolution (#20160)	2025-08-29 16:19:45 -07:00
src	[ty] don't assume that deferred type inference means deferred name resolution (#20160)	2025-08-29 16:19:45 -07:00
tests	[ty] Track open files in the server (#19264)	2025-07-18 19:33:35 +05:30
build.rs
Cargo.toml	[ty] Avoid overcounting shared memory usage (#19773)	2025-08-06 15:32:02 -04:00
mdtest.py
mdtest.py.lock