Skip to content

Avoid calling join during semantic analysis #3316

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

Closed
JukkaL opened this issue May 4, 2017 · 1 comment · Fixed by #3560
Closed

Avoid calling join during semantic analysis #3316

JukkaL opened this issue May 4, 2017 · 1 comment · Fixed by #3560
Labels
bug mypy got something wrong priority-0-high

Comments

@JukkaL
Copy link
Collaborator

JukkaL commented May 4, 2017

We shouldn't call join during semantic analysis, since the MROs of classes may be incomplete and other things may be inconsistent, potentially resulting in crashes.

This comment has additional context: https://github.com/python/mypy/pull/3305/files#r114751204

Quote:

We can't use type joins safely during semantic analysis, since MROs may be incomplete :-(

One potential way to fix this would be to postpone all joins to a new, fourth semantic analysis pass. That sounds risky though, so for the 0.510 release we could just use Any here as the fallback as a temporary workaround.

This has happened so many times that I've been considering asserting during joins and other type operations that need MROs that they aren't called during semantic analysis, at least when running tests.

JukkaL added a commit that referenced this issue May 4, 2017
MROs may not be populated yet, so the join may crash. See #3316
for additional context. Fixes #3315.
@JukkaL JukkaL added bug mypy got something wrong priority-0-high labels May 4, 2017
JukkaL added a commit that referenced this issue May 4, 2017
MROs may not be populated yet during semantic analysis, so the join 
may crash when we have a forward reference within a named tuple. 
See #3316 for additional context. Fixes #3315.

Note that as a side effect, the fallback type of named tuples is now has 
an `Any` item type.
@ilevkivskyi
Copy link
Member

It turns out there is a twin issue #2489. Should we keep open all the three issues: this one, #2489, and #3319?

gvanrossum pushed a commit that referenced this issue Jun 21, 2017
Move join to happen after semantic analysis to avoid crash due to
incomplete MRO in TypeInfo. The implementation uses a new semantic
analysis 'patch' phase.

Fixes #3319. Fixes #2489. Fixes #3316.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug mypy got something wrong priority-0-high
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants