[ty] Share definition resolution between type inference and IDE features - #28032
Open
AlexWaygood wants to merge 1 commit into
Open
[ty] Share definition resolution between type inference and IDE features#28032AlexWaygood wants to merge 1 commit into
AlexWaygood wants to merge 1 commit into
Conversation
Typing conformance resultsNo changes detected ✅Current numbersThe percentage of diagnostics emitted that were expected errors held steady at 97.79%. The percentage of expected errors that received a diagnostic held steady at 94.33%. The number of fully passing files held steady at 112/136. |
Memory usage reportSummary
Significant changesClick to expand detailed breakdownprefect
|
|
Member
|
I'll add @lerebear as reviewer, given that he has been thinking about how to share more semantic APIs with the LSP |
AlexWaygood
force-pushed
the
alex/refactor-goto-definition
branch
from
August 25, 2026 16:11
0973eb9 to
5310792
Compare
AlexWaygood
force-pushed
the
alex/refactor-goto-definition
branch
from
August 25, 2026 18:31
5310792 to
1bcca85
Compare
Merging this PR will not alter performance
Comparing Footnotes
|
…ython_semantic` and `ty_ide`
AlexWaygood
force-pushed
the
alex/refactor-goto-definition
branch
from
August 26, 2026 22:58
1bcca85 to
e980072
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
This is a behaviour-preserving refactor of definition resolution: navigation targets, docstrings, and existing type-checking results are preserved. The changes are to the API boundaries and the inference work performed internally.
LSP benefits
Go-to-definition and go-to-declaration for ordinary builtins such as
isinstanceno longer request completed inference of the enclosing scope just to check whether numeric-annotation expansion applies. Onlyfloatandcomplexneed that check. Completing scope inference computes and caches types for the scope's expressions, along with diagnostics and other inference data, even though navigation only needs the symbol's definition.The expected benefit is lower navigation latency when scope inference is uncached or has been invalidated by an edit, plus fewer temporary allocations and fewer inference results retained solely for navigation. The savings depend on the workload: cached inference leaves little computation to avoid, and diagnostics may still require the same cached data. This does not guarantee lower steady-state memory usage for the server.
Reuse during type inference
The shared API will support inference-side consumers such as #27634, whose redundant-condition analysis needs source definitions as well as inferred types:
sys.version_info,sys.platform,os.name, ortyping.TYPE_CHECKING. These can be constant for the configured target while still being deliberate compatibility guards, including when accessed through aliases or attributes.tuple[T]and suggesttuple[T, ...]when a tuple of arbitrary length may have been intended.These checks run while the enclosing scope is still being inferred. Using the IDE API to obtain expression types at that point can re-enter inference of the same scope, causing avoidable Salsa query cycles and repeated work. The shared helpers instead accept an explicit scope or an already-inferred receiver type, allowing these checks to reuse the existing name, import, and member-resolution rules without requesting completed inference of the current scope. Pydantic's existing annotation-alias lookup is also migrated to this API.
Diff overview
definition_resolution, preserving their lookup algorithms. Numeric-annotation expansion and stub-to-implementation mapping remain inide_support.float/complexinference guard described above. The remaining edits adapt parameters, imports, and visibility, and document the shared API's contracts.