"AssertionError: Should never get here in normal mode" when using --follow-imports silent

[petergaultney]

• What is the actual behavior/output?
  AssertionError on running mypy test.py --follow-imports silent --disallow-untyped-defs
• What is the behavior/output you expect?
  No AssertionError
• What are the versions of mypy and Python you are using?
  .610, Python 3.6.5 from anaconda
  Do you see the same issue after installing mypy from Git master?
  Haven't tried this.
• What are the mypy flags you are using? (For example --strict-optional)
  --follow-imports silent --disallow-untyped-defs (it doesn't seem to happen if I remove --follow-imports silent)
• If mypy crashed with a traceback, please paste
  the full traceback below.

Traceback (most recent call last):
  File "/Users/peter/sw/anaconda3/envs/pycharm_me/bin/mypy", line 11, in <module>
    sys.exit(console_entry())
  File "/Users/peter/sw/anaconda3/envs/pycharm_me/lib/python3.6/site-packages/mypy/__main__.py", line 7, in console_entry
    main(None)
  File "/Users/peter/sw/anaconda3/envs/pycharm_me/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 "/Users/peter/sw/anaconda3/envs/pycharm_me/lib/python3.6/site-packages/mypy/main.py", line 148, in type_check_only
    fscache=fscache)
  File "/Users/peter/sw/anaconda3/envs/pycharm_me/lib/python3.6/site-packages/mypy/build.py", line 185, in build
    flush_errors, fscache)
  File "/Users/peter/sw/anaconda3/envs/pycharm_me/lib/python3.6/site-packages/mypy/build.py", line 285, in _build
    graph = dispatch(sources, manager)
  File "/Users/peter/sw/anaconda3/envs/pycharm_me/lib/python3.6/site-packages/mypy/build.py", line 2398, in dispatch
    process_graph(graph, manager)
  File "/Users/peter/sw/anaconda3/envs/pycharm_me/lib/python3.6/site-packages/mypy/build.py", line 2684, in process_graph
    process_fresh_modules(graph, prev_scc, manager)
  File "/Users/peter/sw/anaconda3/envs/pycharm_me/lib/python3.6/site-packages/mypy/build.py", line 2770, in process_fresh_modules
    graph[id].fix_cross_refs()
  File "/Users/peter/sw/anaconda3/envs/pycharm_me/lib/python3.6/site-packages/mypy/build.py", line 1853, in fix_cross_refs
    self.options.use_fine_grained_cache)
  File "/Users/peter/sw/anaconda3/envs/pycharm_me/lib/python3.6/site-packages/mypy/fixup.py", line 25, in fixup_module
    node_fixer.visit_symbol_table(tree.names)
  File "/Users/peter/sw/anaconda3/envs/pycharm_me/lib/python3.6/site-packages/mypy/fixup.py", line 95, in visit_symbol_table
    self.visit_type_info(value.node)
  File "/Users/peter/sw/anaconda3/envs/pycharm_me/lib/python3.6/site-packages/mypy/fixup.py", line 48, in visit_type_info
    base.accept(self.type_fixer)
  File "/Users/peter/sw/anaconda3/envs/pycharm_me/lib/python3.6/site-packages/mypy/types.py", line 512, in accept
    return visitor.visit_instance(self)
  File "/Users/peter/sw/anaconda3/envs/pycharm_me/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 "/Users/peter/sw/anaconda3/envs/pycharm_me/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

This seems to happen when I make a change to add a new error (e.g. missing type in function def) where there wasn't one before.
This doesn't seem to happen if I'm not importing botocore.vendored requests. But it also does not need to be used in the same function that has the new error.
I can work around it by blowing away the .mypy_cache directory. But future changes to test.py just make the error come back again.

I think it's likely related to botocore in some way, but obviously the assertion is mypy's fault.

mypy-610-assertion.zip

[petergaultney]

Follow-up: I can also reproduce using the 'real' requests library, so it's not botocore that's at fault.

import requests

def returns_int(an_arg) -> requests.Response:
    if an_arg == "an arg":
        return 3
    else:
        return 2


def returns_str(something: str) -> str:
    return 0

run mypy --follow-imports silent once and it works fine. Then change any of the type annotations (e.g. something: int) and it will assert.

[petergaultney]

I'll go ahead and confirm that --follow-imports skip doesn't cause the error. It definitely appears to be related to --follow-imports silent. At this point I'd guess that it wouldn't have to be any particular external module either, just as long as there's an import that it's following for type information.

[gvanrossum]

I cannot reproduce this with the master branch. Can you try that?

[gvanrossum]

Possibly duplicate of #5192? (Which is closed as a duplicate of #4287, which is still open.)

I'd still like to hear whether you can repro this on master.

[petergaultney]

I believe I can. I just cloned mypy (git clone --recurse-submodules https://github.com/python/mypy.git), created a new virtualenv (with pipenv - hopefully that's not relevant), built and installed mypy (python -m pip install -U ., ensuring that I was using the virtualenv to build it), and then ran my test within that virtualenv.

For what it's worth, I'm testing this with Python 3.6.5 from Anaconda. I have not tried it in 3.7.

It does definitely require running mypy test.py --follow-imports silent twice - the first time will succeed, and then you have to make a change to the typing in the file and run it again. It's only the second time that it fails.

I used an absolute path to my mypy bin in my venv to ensure that it was using the master version, as well.

[gvanrossum]

I still cannot repro this. Do you have anything in mypy.ini or in ~/mypy.ini?

Using mypy 0.620, when I run mypy test.py --follow-imports=silent, with the following contents of test.py:

import requests

def returns_int(an_arg) -> requests.Response:
    if an_arg == "an arg":
        return 3
    else:
        return 2

def returns_str(something: str) -> str:
    return 0

I get these errors:

test.py:5: error: Incompatible return value type (got "int", expected "Response")
test.py:7: error: Incompatible return value type (got "int", expected "Response")
test.py:10: error: Incompatible return value type (got "int", expected "str")

I then make an edit to test.py, changing something: str to something: int and re-run the same command -- and I get the same output. No crash.

[petergaultney]

Honestly, I'm just confused now. I had been really careful last week when I set up my environment and it was consistently reproducible. I haven't really touched anything about my Python setup since last week, either. But I just tried to reproduce it again and can't.

The only thing I can imagine is that somehow the mypycache might've been initially generated with an older version of mypy and then the newer version was still crashing with that old cache? But I have tried recreating the cache with 0.620 (my globally installed version) and then running mypy master after the first check, and I still can't reproduce it. Maybe the original cache was created with 0.610? I need version control for my scratch environment. :P

I'm closing the ticket. If it ever pops up again I can come back and reopen. I'll be scratching my head over this one for a while, though.

[gvanrossum]

Hm, the cache is normally invalidated when you use a different mypy version (the mypy version is actually baked into the cache files and compared). In any case, I'm glad we can at least agree that it doesn't seem reproducible with current mypy master.