Fix crash when unpacking a fixed-length tuple inside a tuple type - #21934
Open
afonsojanu wants to merge 1 commit into
Open
Fix crash when unpacking a fixed-length tuple inside a tuple type#21934afonsojanu wants to merge 1 commit into
afonsojanu wants to merge 1 commit into
Conversation
tuple_fallback() only knew how to handle two shapes for an unpacked item inside a tuple: a TypeVarTuple (via its upper bound) or a variable-length tuple Instance. Unpacking a fixed-length tuple, which PEP 646 also allows and which shows up easily through a type alias like `type Outer = tuple[bool, *tuple[int, str]]`, fell through to the NotImplementedError branch and crashed mypy outright whenever that tuple type needed its fallback computed (e.g. when checking it against a generic upper bound during overload resolution). Handle the TupleType case the same way as the others: recurse into its own tuple_fallback() to get the right combined element type, then fold that into the union like everything else here does. Fixes python#21933.
Contributor
|
According to mypy_primer, this change doesn't affect type check results on a corpus of open source code. ✅ |
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.
Fixes #21933.
The crash happens in
tuple_fallback(). That function knows how to fold an unpacked item into the tuple's combined fallback type in two cases: aTypeVarTuple(using its upper bound) or a variable-length tupleInstance. It never learned about a third case PEP 646 also allows, unpacking a plain fixed-length tuple, so anything that hit this path raisedNotImplementedErrorand mypy crashed outright.This is easy to trigger with a type alias:
OuterunpacksInner, a fixed tuple, not a variable-length one or a TypeVarTuple, sotuple_fallbackhad nowhere to go. The reporter's repro neededdeque[Outer]specifically because computing the fallback here only gets triggered along certain code paths (checking a generic type argument against its bound during overload resolution, in this case), but the underlying gap is intuple_fallbackitself, independent ofdeque.The fix recurses into
tuple_fallback()for the nestedTupleTypeto get its own combined element type, then folds that into the union the same way the other two branches already do.Added a regression test to
pythoneval.testusing the reporter's original repro (it needs the realcollectionsstub, so it belongs there rather than in one of the in-processcheck-*.testfiles). Confirmed it reproduces the exactINTERNAL ERRORcrash from the issue before the fix and passes cleanly after. Ran the full test suite locally, no regressions.