[ty] Fix contravariant type variable bound checking in specialization inference#22488
Merged
dcreager merged 3 commits intoastral-sh:mainfrom Jan 12, 2026
Merged
[ty] Fix contravariant type variable bound checking in specialization inference#22488dcreager merged 3 commits intoastral-sh:mainfrom
dcreager merged 3 commits intoastral-sh:mainfrom
Conversation
… inference ## Summary Correctly handle upper bounds for contravariant type variables during specialization inference. Previously, the type checker incorrectly applied covariant subtyping rules, requiring the actual type to directly satisfy the bound rather than checking for a valid intersection. In contravariant positions, subtyping relationships are inverted. The bug caused valid code like `f(x: Contra[str])` where `f` expects `Contra[T: int]` to be incorrectly rejected, when it should solve `T` to `Never` (the intersection of `int` and `str`). Closes astral-sh/ty#2427 ## Details - Added `is_contravariant()` helper to `TypeVarVariance` in `variance.rs` - Updated `SpecializationBuilder::infer_map_impl` in `generics.rs` to treat bounds and constraints differently based on variance: * Skip immediate `ty <: bound` check for contravariant upper bounds * Flip constraint check to `constraint <: ty` for contravariant positions - Added test case for bounded contravariant type variables in `variance.md` - All 308 mdtest cases pass & 150 ty_python_semantic unit tests pass
bxff
requested review from
AlexWaygood,
carljm,
dcreager and
sharkdp
as code owners
Diagnostic diff on typing conformance testsNo changes detected when running ty on typing conformance tests ✅ |
|
AlexWaygood
requested review from
ibraheemdev
and removed request for
AlexWaygood
dcreager
approved these changes
Jan 12, 2026
Member
dcreager
left a comment
dcreager
left a comment
There was a problem hiding this comment.
Thank you for this! This has been a gap in our old solver for quite some time.
I made one change to the logic, described below, and also added a corresponding test using the legacy typevar syntax.
Comment on lines
1881
to
1886
| // In a contravariant position, the formal type variable is a subtype of | ||
| // the actual type (`T <: ty`). Since we also have the upper bound | ||
| // constraint `T <: bound`, we just need to ensure that the intersection | ||
| // of `ty` and `bound` is non-empty. Since `Never` is always a valid | ||
| // intersection if the types are disjoint, we don't need to perform any | ||
| // check here. |
Member
There was a problem hiding this comment.
This explanation is correct, but we also have to solve to the intersection, and not just use the provided actual parameter directly like you did below.
Contributor
Author
There was a problem hiding this comment.
Thanks for the review :)
|
| Lint rule | Added | Removed | Changed |
|---|---|---|---|
invalid-argument-type |
2 | 2 | 3 |
invalid-return-type |
0 | 0 | 6 |
invalid-assignment |
0 | 0 | 5 |
possibly-missing-attribute |
0 | 3 | 1 |
unused-ignore-comment |
1 | 2 | 0 |
invalid-await |
0 | 2 | 0 |
unresolved-attribute |
0 | 0 | 2 |
| Total | 3 | 9 | 17 |
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
Correctly handle upper bounds for contravariant type variables during specialization inference. Previously, the type checker incorrectly applied covariant subtyping rules, requiring the actual type to directly satisfy the bound rather than checking for a valid intersection.
In contravariant positions, subtyping relationships are inverted. The bug caused valid code like
f(x: Contra[str])wherefexpectsContra[T: int]to be incorrectly rejected, when it should solveTtoNever(the intersection ofintandstr).Closes astral-sh/ty#2427
Details
is_contravariant()helper toTypeVarVarianceinvariance.rsSpecializationBuilder::infer_map_implingenerics.rsto treat bounds and constraints differently based on variance:ty <: boundcheck for contravariant upper boundsconstraint <: tyfor contravariant positionsvariance.md