Crash with "AssertionError: Should never get here in normal mode" #5192
Labels
Comments
|
Following a similar, older report (#3852), attached is a zip of the |
|
Confirmed on mypy master. |
|
Reproduced on master as: $ # in a clean venv, activated
$ python3 -m pip install -U git+git://github.com/python/mypy.git
[...]
$ git clone https://github.com/pypa/pip.git --depth=1
[...]
$ cd pip
$ git fetch origin 13a749de24448d553b73abbb119d6a9e42531089
$ git checkout 13a749de24448d553b73abbb119d6a9e42531089
$ mypy src
[...]
$ mypy src
Traceback (most recent call last):
File "/tmp/mypy-venv/bin/mypy", line 11, in <module>
sys.exit(console_entry())
File "/tmp/mypy-venv/lib/python3.6/site-packages/mypy/__main__.py", line 7, in console_entry
main(None)
File "/tmp/mypy-venv/lib/python3.6/site-packages/mypy/main.py", line 91, in main
res = type_check_only(sources, bin_dir, options, flush_errors, fscache) # noqa
File "/tmp/mypy-venv/lib/python3.6/site-packages/mypy/main.py", line 148, in type_check_only
fscache=fscache)
File "/tmp/mypy-venv/lib/python3.6/site-packages/mypy/build.py", line 181, in build
flush_errors, fscache)
File "/tmp/mypy-venv/lib/python3.6/site-packages/mypy/build.py", line 286, in _build
graph = dispatch(sources, manager)
File "/tmp/mypy-venv/lib/python3.6/site-packages/mypy/build.py", line 2440, in dispatch
process_graph(graph, manager)
File "/tmp/mypy-venv/lib/python3.6/site-packages/mypy/build.py", line 2726, in process_graph
process_fresh_modules(graph, prev_scc, manager)
File "/tmp/mypy-venv/lib/python3.6/site-packages/mypy/build.py", line 2812, in process_fresh_modules
graph[id].fix_cross_refs()
File "/tmp/mypy-venv/lib/python3.6/site-packages/mypy/build.py", line 1895, in fix_cross_refs
self.options.use_fine_grained_cache)
File "/tmp/mypy-venv/lib/python3.6/site-packages/mypy/fixup.py", line 25, in fixup_module
node_fixer.visit_symbol_table(tree.names)
File "/tmp/mypy-venv/lib/python3.6/site-packages/mypy/fixup.py", line 95, in visit_symbol_table
self.visit_type_info(value.node)
File "/tmp/mypy-venv/lib/python3.6/site-packages/mypy/fixup.py", line 48, in visit_type_info
base.accept(self.type_fixer)
File "/tmp/mypy-venv/lib/python3.6/site-packages/mypy/types.py", line 513, in accept
return visitor.visit_instance(self)
File "/tmp/mypy-venv/lib/python3.6/site-packages/mypy/fixup.py", line 156, in visit_instance
inst.type = lookup_qualified_typeinfo(self.modules, type_ref, self.quick_and_dirty)
File "/tmp/mypy-venv/lib/python3.6/site-packages/mypy/fixup.py", line 246, in lookup_qualified_typeinfo
assert quick_and_dirty, "Should never get here in normal mode"
AssertionError: Should never get here in normal mode |
|
Removing |
|
I really hoped we will not see this ever again :-( Just to clarify, is this a regression in 0.610 (i.e. does it work with mypy 0.600)? Also, could you please try to play with mypy config to see what exactly causes a breakage? Ideally it would be great to have a minimalistic repro, but I understand this may be hard to find. |
|
No crash with mypy 0.600. Also, it no longer occurs on pip's master; I added a missing stub for a vendored library, which seems to have fixed this. It does still occur on pypa/pip@13a749d. Updated the reproduction case above to checkout to that. |
|
Is there any way to know which file mypy is processing when it crashes? I have a gut feeling it's going to be Minimal reproduction mypy config, with the same source tree. [mypy-pip/_vendor/*]
ignore_errors = True |
You can run mypy with |
The crash still occurs on mypy 0.600 and 0.610 with the source tree reduced to (the minimal configuration): All the |
|
Here's the smallest reproduction case I can come up with (crashes both 0.600 and 0.610):
one.py import logging
def func(value):
# type: (Any) -> None
passtwo.py from collections import namedtuple
class MyClass(namedtuple('MyClass', undefined_variable)):
passsetup.cfg [mypy-ignored/*]
ignore_errors = True
Things that prevent the crash:
Is it just me or does this look very weird? ._. |
|
Output of Click to see output of |
Yes it is. But I think I understand the idea, it seems to me all this weird dance is needed to convince mypy it needs to deserialize |
This crashes as well. |
|
OK, my hypothesis has another confirmation, just running a single file with |
|
So, close as a duplicate and add crash label to #4287? |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
🐛 Python 3.6.5, mypy 0.610
Reproducible on https://github.com/pypa/pip master. Running
tox -e mypyon that repo a second time or later, results in an error the second time.mypy configuration:
mypy output/traceback:
The text was updated successfully, but these errors were encountered: