[ty] Resolve TypeVars in call_signature_details parameter types#23149
Merged
BurntSushi merged 1 commit intoastral-sh:mainfrom Feb 17, 2026
Merged
Conversation
knutwannheden
requested review from
AlexWaygood,
BurntSushi,
Gankra,
MichaReiser,
carljm,
dcreager and
sharkdp
as code owners
AlexWaygood
added
server
Typing conformance resultsNo changes detected ✅ |
|
knutwannheden
force-pushed
the
resolve-typevars-in-call-signature-details
branch
from
655625a to
320026a
Compare
Contributor
Author
|
Fixed the CI failures and force-pushed:
|
Contributor
|
FYI @dcreager |
Contributor
|
@dcreager is out for the next week so we shouldn't wait for his review here. The generics stuff looks reasonable to me, but I'll assign this to @BurntSushi for review on the LSP side. |
BurntSushi
reviewed
Feb 17, 2026
Contributor
Author
Thanks for the review. I addressed your comment, resolved some merge conflicts that were reported on GitHub, and pushed the updates. |
Memory usage reportMemory usage unchanged ✅ |
Member
|
@knutwannheden Can you rebase this on |
Contributor
Author
|
@BurntSushi The PR is already rebased. |
Member
|
It looks like you merged |
Contributor
Author
|
I see. Let me fix that. |
Member
|
I don't see any merge conflicts here. @BurntSushi maybe try refreshing the webpage? |
Previously, `call_signature_details` populated `parameter_types` from raw `param.annotated_type()`, which left function-level TypeVars unresolved. For example, calling a generic function `pair[T](a: T, b: T)` with a `str` argument would report both parameters as type `T` instead of `str`. This change adds a `check_types` pass after `match_parameters` to infer TypeVar specializations from the actual argument types at the call site. The inferred specialization is then applied to each parameter's annotated type via `apply_specialization`, which resolves TypeVars while preserving non-TypeVar annotations unchanged. Two changes are needed: - Switch from `from_arguments` to `from_arguments_typed` so argument types are available for TypeVar inference - Call `check_types_impl` and use `binding.specialization()` to apply the inferred specialization to annotated types
knutwannheden
force-pushed
the
resolve-typevars-in-call-signature-details
branch
from
e4867d0 to
7b9b0ea
Compare
Contributor
Author
|
Now it is a single fast-forward commit. |
Member
|
@AlexWaygood Weird. I did refresh too (a few times). Maybe GitHub hiccup? |
Member
|
@knutwannheden Thank you! |
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
5 participants
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.
Previously,
call_signature_detailspopulatedparameter_typesfrom rawparam.annotated_type(), which left function-level TypeVars unresolved. For example, calling a generic functionpair[T](a: T, b: T)with astrargument would report both parameters as typeTinstead ofstr.This change adds a
check_typespass aftermatch_parametersto infer TypeVar specializations from the actual argument types at the call site. The inferred specialization is then applied to each parameter's annotated type viaapply_specialization, which resolves TypeVars while preserving non-TypeVar annotations unchanged.Two changes are needed:
from_argumentstofrom_arguments_typedso argument types are available for TypeVar inferencecheck_types_impland usebinding.specialization()to apply the inferred specialization to annotated typesAn alternative would be to add a separate
call_signature_details_with_resolved_typesfunction to avoid changing the existing behavior, but since resolved types are strictly more useful for consumers (signature help, completions, IDE tooling), updating the existing function seems preferable.