[ty] Implement constraint implication for compound types#21366
Merged
[ty] Implement constraint implication for compound types#21366
Conversation
dcreager
requested review from
AlexWaygood,
carljm and
sharkdp
as code owners
Diagnostic diff on typing conformance testsNo changes detected when running ty on typing conformance tests ✅ |
|
dcreager
force-pushed
the
dcreager/deep-comparison
branch
2 times, most recently
from
f3b001d to
b39afa7
Compare
Member
|
Are the primer hits here expected? |
|
dcreager
force-pushed
the
dcreager/deep-comparison
branch
from
b39afa7 to
8623176
Compare
Member
Author
They were not! Latest patch disappears them |
Contributor
|
I am planning to review this, but postponing to tomorrow, since Doug is out today anyway. |
Member
Author
Thank you! No rush |
sharkdp
approved these changes
Nov 13, 2025
crates/ty_python_semantic/resources/mdtest/type_properties/implies_subtype_of.md
Show resolved
Hide resolved
crates/ty_python_semantic/resources/mdtest/type_properties/implies_subtype_of.md
Show resolved
Hide resolved
Comment on lines
+1449
to
+1460
| // From here on out we know that both constraints constrain the same typevar. The | ||
| // clause above will propagate all that we know about the current typevar relative to | ||
| // other typevars, producing constraints on this typevar that have concrete lower/upper | ||
| // bounds. That means we can skip the simplifications below if any bound is another | ||
| // typevar. | ||
| if left_constraint.lower(db).is_type_var() | ||
| || left_constraint.upper(db).is_type_var() | ||
| || right_constraint.lower(db).is_type_var() | ||
| || right_constraint.upper(db).is_type_var() | ||
| { | ||
| continue; | ||
| } |
Contributor
There was a problem hiding this comment.
This sounds like an optimization, but seems to be required for correctness?
Member
Author
There was a problem hiding this comment.
Yep, as described (and clarified/fixed) in much more detail in #21463
Co-authored-by: David Peter <sharkdp@users.noreply.github.com>
* origin/main: (59 commits) [ty] Improve diagnostic range for `non-subscriptable` diagnostics (#21461) [ty] Improve literal promotion heuristics (#21439) [ty] Further improve details around which expressions should be deferred in stub files (#21456) [ty] Improve generic class constructor inference (#21442) [ty] Propagate type context through conditional expressions (#21443) [ty] Suppress completions when introducing names with `as` [ty] Add panic-by-default await methods to `TestServer` (#21451) [ty] name is parameter and global is a syntax error (#21312) [ty] Fixup a few details around version-specific dataclass features (#21453) [ty] Support attribute-expression `TYPE_CHECKING` conditionals (#21449) [ty] Support stringified annotations in value-position `Annotated` instances (#21447) [ty] Type inference for genererator expressions (#21437) [ty] Make `__getattr__` available for `ModuleType` instances (#21450) [ty] Increase default receive timeout in tests to 10s (#21448) [ty] Add synthetic members to completions on dataclasses (#21446) [ty] Support legacy `typing` special forms in implicit type aliases (#21433) Bump 0.14.5 (#21435) [ty] Support `type[…]` and `Type[…]` in implicit type aliases (#21421) [ty] Respect notebook cell boundaries when adding an auto import (#21322) Update PyCharm setup instructions (#21409) ...
dcreager
added a commit
that referenced
this pull request
Nov 14, 2025
* origin/main: [ty] Implement constraint implication for compound types (#21366)
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.
This PR updates the constraint implication type relationship to work on compound types as well. (A compound type is a non-atomic type, like
list[T].)The goal of constraint implication is to check whether the requirements of a constraint imply that a particular subtyping relationship holds. Before, we were only checking atomic typevars. That would let us verify that the constraint set
T ≤ boolimplies thatTis always a subtype ofint. (In this case, the lhs of the subtyping check,T, is an atomic typevar.)But we weren't recursing into compound types, to look for nested occurrences of typevars. That means that we weren't able to see that
T ≤ boolimplies thatCovariant[T]is always a subtype ofCovariant[int].Doing this recursion means that we have to carry the constraint set along with us as we recurse into types as part of
has_relation_to, by adding constraint implication as a newTypeRelationvariant. (Before it was just a method onConstraintSet.)