[ty] Fix invariant gradual tuple materialization ranges - #27946
Open
carljm wants to merge 4 commits into
Open
Conversation
Typing conformance resultsNo changes detected ✅Current numbersThe percentage of diagnostics emitted that were expected errors held steady at 97.68%. The percentage of expected errors that received a diagnostic held steady at 93.44%. The number of fully passing files held steady at 109/136. |
Memory usage reportMemory usage unchanged ✅ |
|
carljm
marked this pull request as ready for review
August 21, 2026 00:59
This was referenced Aug 21, 2026
dhruvmanila
approved these changes
Aug 21, 2026
Comment on lines
+628
to
+632
| def symbolic(value: Variadic[*Ts]) -> int: | ||
| match value: | ||
| case Variadic(): | ||
| reveal_type(value) # revealed: Variadic[*tuple[*Ts@symbolic]] | ||
| return 1 |
Member
There was a problem hiding this comment.
Should we use assert_never instead?
def symbolic(value: Variadic[*Ts]) -> None:
match value:
case Variadic():
reveal_type(value) # revealed: Variadic[*tuple[*Ts@symbolic]]
case _:
assert_never(value)
Comment on lines
+638
to
+642
| def empty(value: Variadic[()]) -> int: | ||
| match value: | ||
| case Variadic(): | ||
| reveal_type(value) # revealed: Variadic[()] | ||
| return 1 |
Comment on lines
+648
to
+652
| def nonempty(value: Variadic[int]) -> int: | ||
| match value: | ||
| case Variadic(): | ||
| reveal_type(value) # revealed: Variadic[int] | ||
| return 1 |
dhruvmanila
reviewed
Aug 21, 2026
| matches!(tuple, TupleSpec::Variable(tuple) | ||
| if tuple.prefix_elements().is_empty() | ||
| && tuple.suffix_elements().is_empty() | ||
| && matches!(tuple.variable(), VariableSegment::Homogeneous(Type::Dynamic(_)))) |
Member
There was a problem hiding this comment.
Should we resolve type aliases for the variable type before comparing it to the dynamic type? So, something like following is also correct:
type Dynamic = Any
# Passes.
static_assert(is_subtype_of(Box[tuple[int]], Top[Box[tuple[Any, ...]]]))
# Incorrectly fails: Dynamic is an alias for Any.
static_assert(is_subtype_of(Box[tuple[int]], Top[Box[tuple[Dynamic, ...]]]))
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
2 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.
tuple[Any, ...]can materialize to an exact built-in tuple of any length. Currently we bottom-materialize this type incorrectly. We give its bottom materialization astuple[Never, ...], which we currently simplify totuple[()], but neither of these types is a subtype of every possible tuple type, which the bottom materialization oftuple[Any, ...]should be. As a result, valid specializations can be rejected, and an exhaustive variadic-generic class pattern can appear non-exhaustive.The full fix here (a correct bottom materialization of
tuple[Any, ...]) will be more invasive, and I prefer to delay that until we've made some more general decisions about how we want to treat bottom materializations and their (non-?)equivalence toNever, and fixed the property tests.This limited fix just special-cases
tuple[Any, ...]inside invariant specialization type relations, avoiding using the bottom materialization oftuple[Any, ...]rather than fixing it. This is a pre-requisite to avoid regression in my next steps on fixing the property tests (and another fix I'm working on). The added tests here are correct, so at least this is moving us in the right direction and locking in some better behaviors, even if the implementation isn't what it should be yet.This is an independent prerequisite for both #27920 and #27943. It does not change
Nevertuple normalization or static tuple disjointness.Test plan
The stable property suite has two existing failures involving
tuple[Never]disjointness, reproduced both with and without this change. Those are addressed by the separate tuple-disjointness work in #27920.