Fix Literal strings containing pipe characters #17148
Merged
Conversation
This file contains 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
This comment has been minimized.
This comment has been minimized.
|
According to mypy_primer, this change doesn't affect type check results on a corpus of open source code. ✅ |
hauntsaninja
approved these changes
Apr 21, 2024
andersk
added a commit
to andersk/mypy
that referenced
this pull request
Jul 26, 2024
Commit 1072c78 (python#17148) converted all quoted types into RawExpressionType, which raised an AssertionError when accepting a TypeTriggersVisitor. Fixes python#17587. Signed-off-by: Anders Kaseorg <[email protected]>
JelleZijlstra
pushed a commit
that referenced
this pull request
Jul 26, 2024
) Commit 1072c78 (#17148) converted all quoted types into `RawExpressionType`, which raised an `AssertionError` when `accept`ing a `TypeTriggersVisitor`. - Fixes #17574. - Fixes #17587. Signed-off-by: Anders Kaseorg <[email protected]>
hauntsaninja
pushed a commit
that referenced
this pull request
Jul 27, 2024
) Commit 1072c78 (#17148) converted all quoted types into `RawExpressionType`, which raised an `AssertionError` when `accept`ing a `TypeTriggersVisitor`. - Fixes #17574. - Fixes #17587. Signed-off-by: Anders Kaseorg <[email protected]>
|
I am going to revert this. This breaks a fundamental invariant that synthetic types do not leak from semantic analysis. It looks like the code that caused the problem in the first place was intended to support something like this: x: Literal["A", "B"]
A = Literal[1, 2]
B = Literal[3, 4]
reveal_type(x) # Literal[1, 2, 3, 4]But I am not sure it ever worked (or at least not consistently). Instead I am going to change (either limit or completely prohibit) this behavior. |
ilevkivskyi
added a commit
that referenced
this pull request
Aug 4, 2024
This reverts commit 1072c78.
ilevkivskyi
added a commit
that referenced
this pull request
Aug 4, 2024
mr-c
pushed a commit
to mr-c/mypy
that referenced
this pull request
Aug 14, 2024
md384
pushed a commit
to md384/mypy
that referenced
this pull request
Aug 14, 2024
Reverts python#17148 (cherry picked from commit bc39f17)
hauntsaninja
pushed a commit
that referenced
this pull request
Aug 24, 2024
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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 #16367
During semantic analysis, we try to parse all strings as types, including those inside Literal[]. Previously, we preserved the original string in the
UnboundType.original_str_exprattribute, but if a type is parsed as a Union, we didn't have a place to put the value.This PR instead always wraps string types in a RawExpressionType node, which now optionally includes a
.nodeattribute containing the parsed type. This way, we don't need to worry about preserving the original string as a custom attribute on different kinds of types that can appear in this context.The downside is that more code needs to be aware of RawExpressionType.