| FazBrowse GitHub Viewer | Trending | | Home |
| Tools: [Download Repo ZIP] [Original HTTPS Page] |
Sorry, something went wrong.
|
According to mypy_primer, this change doesn't affect type check results on a corpus of open source code. ✅ |
Sorry, something went wrong.
| Back | FazBrowse Home | New Git URL |
This MR fixes two possible crashes related to builtins.int not being ready yet when a Literal is analyzed. One happens if builtins.int is entirely unavailable, and the other if builtins.int is only available as a placeholder node.
The first case is responsible for the crash if typeshed imports Literal from typing instead of typing_extensions. Mypy has Literal available during the first pass of builtins.pyi, which means it encounters Literal[0] before it's seen the class int statement: python/typeshed#11247
The second case occurs if builtins.int is a subclass of something that's slow to resolve, which turns up if you try to make builtins.int inherit from numbers.Integral: python/typeshed#12894
Both cases are resolved by deferring during TypeAnalyser.analyze_literal_param if the type of the literal isn't ready yet.
After fixing those, an additional issue became apparent, where the r.h.s of a TypeAlias assignment is ready but TypeAlias itself isn't ready yet, which caused mypy to say it wasn't a valid TypeAlias. An additional check and defer within SemanticAnalyzer.visit_assignment_stmt fixes that. This didn't happen before because typing_extensions.Literal and typing_extensions.TypeAlias resolved at the same speed, so it wasn't noticeable. Some problems shows up for deferred on any unresolved lhs type, so I restricted it to only defer for unresolved lhs types which were imported from typing or typing_extensions.