-
-
Notifications
You must be signed in to change notification settings - Fork 2.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Internal Error with forward references #3881
Comments
Confirmed. But could be a duplicate of #3836. |
Yes, this is very similar to #3836, but 100% identical. We currently have half a dozen of crashes with the same root cause: forward references to "synthetic" types are not processed correctly during semantic analysis. @JukkaL are you working on this? If not, then I could take care of this. I think we can fix all these crashes and other issues simply by adding few callbacks after semantic passes, as we discussed some time ago. |
@gvanrossum Yes, sorry, I meant not 100% identical. OK, I will give it a try, this is not a very small task, but since I was thinking about it for some time already I think there is a good chance it will be straightforward to solve. |
@ilevkivskyi Thanks! As a first step it's fine to focus on fixing the crashes. Mypy would still generate an error when trying to use a forward reference. This should be easier than making the forward references work correctly. Our current plan is to get at least the crashes fixed by around mid September, before the next mypy release. |
Forward references didn't work with anything apart from classes, for example this didn't work: ``` x: A A = NamedTuple('A', [('x', int)]) ``` The same situation was with `TypedDict`, `NewType`, and type aliases. The root problem is that these synthetic types are neither detected in first pass, nor fixed in third pass. In certain cases this can lead to crashes (first six issues below are various crash scenarios). This fixes these crashes by applying some additional patches after third pass. Here is the summary of the PR: * New simple wrapper type `ForwardRef` with only one field `link` is introduced (with updates to type visitors) * When an unknown type is found in second pass, the corresponding `UnboundType` is wrapped in `ForwardRef`, it is given a "second chance" in third pass. * After third pass I record the "suspicious" nodes, where forward references and synthetic types have been encountered and append patches (callbacks) to fix them after third pass. Patches use the new visitor `TypeReplacer` (which is the core of this PR). Fixes #3340 Fixes #3419 Fixes #3674 Fixes #3685 Fixes #3799 Fixes #3836 Fixes #3881 Fixes #867 Fixes #2241 Fixes #2399 Fixes #1701 Fixes #3016 Fixes #3054 Fixes #2762 Fixes #3575 Fixes #3990
Reporting a bug I found.
Reproducible case:
Note that moving the definition of
AOrB
after the definition ofA
works fine. This seems only to happen when all of the types are forward references. Making the constructor ofB
use a forward reference toAOrB
does not fix the issue either.The text was updated successfully, but these errors were encountered: