[ty] Substitute ParamSpec in overloaded functions#22416
Merged
dhruvmanila merged 2 commits intomainfrom Jan 7, 2026
Merged
Conversation
dhruvmanila
added
bug
dhruvmanila
force-pushed
the
dhruv/paramspec-overload-2
branch
from
9f9f1ea to
b109ac6
Compare
Diagnostic diff on typing conformance testsNo changes detected when running ty on typing conformance tests ✅ |
dhruvmanila
force-pushed
the
dhruv/paramspec-overload-2
branch
from
b109ac6 to
33ab140
Compare
|
dhruvmanila
force-pushed
the
dhruv/paramspec-overload-2
branch
from
33ab140 to
0c184fa
Compare
dhruvmanila
requested review from
AlexWaygood,
carljm,
dcreager and
sharkdp
as code owners
dcreager
approved these changes
Jan 6, 2026
Comment on lines
238
to
243
| smallvec_inline![signature.apply_type_mapping_impl( | ||
| db, | ||
| type_mapping, | ||
| tcx, | ||
| visitor | ||
| )] |
Member
There was a problem hiding this comment.
If I'm reading the docs right, smallvec_inline! only works here because result.overloads happens to be a SmallVec with 1 stack-reserved element. If we were to change the type of result.overloads, or even the size of the SmallVec, this would not work anymore. Is it worth using something more future-proof, like wrapping in Either? flat_map just needs to return an iterator.
Either::Right([signature.apply_type_mapping_impl(
db,
type_mapping,
tcx,
visitor,
)]
Member
There was a problem hiding this comment.
I think that's something we can deal with when we change the type. Seems unlikely that we change the type and increasing the size of the small vec isn't an issue.
dhruvmanila
pushed a commit
that referenced
this pull request
Jan 7, 2026
@dhruvmanila encountered this in #22416 — there are two different `TypeMapping` variants for apply a specialization to a type. One operates on a full `Specialization` instance, the other on a partially constructed one. If we move this enum-ness "down a level" it reduces some copy/paste in places where we are operating on a `TypeMapping`.
dhruvmanila
force-pushed
the
dhruv/paramspec-overload-2
branch
from
0c184fa to
714b238
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
3 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.
Summary
fixes: astral-sh/ty#2027
This PR fixes a bug where the type mapping for a
ParamSpecwas not being applied in an overloaded function.This PR also fixes astral-sh/ty#2081 and reveals new diagnostics which doesn't look related to the bug:
The reason is that the type of
future_yisPrefectFuture[int]while the type oftask_addisTask[(x: int, y: int), int]which means that the assignment betweenintandPrefectFuture[int]fails which results in no overload matching. Pyright also raises the invalid argument type error on all three usages offuture_yin those two calls.Test Plan
Add regression mdtest from the linked issue.