Skip to content

Incremental mode crashes on #type: ignore comment on module when it was previously imported #1904

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
Michael0x2a opened this issue Jul 18, 2016 · 1 comment · Fixed by #1912

Comments

@Michael0x2a
Copy link
Collaborator

Michael0x2a commented Jul 18, 2016

Suppose you have the following two files:

a.py

import b  # type: ignore

b.py

# This file can be empty or non-empty

If you delete .mypy_cache then run mypy -i b.py a.py twice, you obtain the following error the second time you run mypy:

Traceback (most recent call last):
  File "/Library/Frameworks/Python.framework/Versions/3.5/lib/python3.5/runpy.py", line 184, in _run_module_as_main
    "__main__", mod_spec)
  File "/Library/Frameworks/Python.framework/Versions/3.5/lib/python3.5/runpy.py", line 85, in _run_code
    exec(code, run_globals)
  File "/Users/michaellee/Work/mypy/mypy/__main__.py", line 5, in <module>
    main(None)
  File "/Users/michaellee/Work/mypy/mypy/main.py", line 40, in main
    res = type_check_only(sources, bin_dir, options)
  File "/Users/michaellee/Work/mypy/mypy/main.py", line 81, in type_check_only
    options=options)
  File "/Users/michaellee/Work/mypy/mypy/build.py", line 178, in build
    dispatch(sources, manager)
  File "/Users/michaellee/Work/mypy/mypy/build.py", line 1339, in dispatch
    process_graph(graph, manager)
  File "/Users/michaellee/Work/mypy/mypy/build.py", line 1480, in process_graph
    process_fresh_scc(graph, scc)
  File "/Users/michaellee/Work/mypy/mypy/build.py", line 1539, in process_fresh_scc
    graph[id].fix_cross_refs()
  File "/Users/michaellee/Work/mypy/mypy/build.py", line 1202, in fix_cross_refs
    fixup_module_pass_one(self.tree, self.manager.modules)
  File "/Users/michaellee/Work/mypy/mypy/fixup.py", line 17, in fixup_module_pass_one
    node_fixer.visit_symbol_table(tree.names)
  File "/Users/michaellee/Work/mypy/mypy/fixup.py", line 75, in visit_symbol_table
    stnode = lookup_qualified_stnode(self.modules, cross_ref)
  File "/Users/michaellee/Work/mypy/mypy/fixup.py", line 237, in lookup_qualified_stnode
    assert '.' in head, "Cannot find %s" % (name,)
AssertionError: Cannot find b

However, just running mypy -i a.py twice or swapping the order of the files and running mypy -a a.py b.py appears to both work fine -- it appears that incremental mode does not behave correctly when it first parses a module normally then encounters it a second time when it's annotated with # type: ignore.

@Michael0x2a Michael0x2a changed the title Bad interaction with # type: ignore and incremental mode Incremental mode crashes on unnecessary #type: ignore comment on module import Jul 19, 2016
@Michael0x2a Michael0x2a changed the title Incremental mode crashes on unnecessary #type: ignore comment on module import Incremental mode crashes on #type: ignore comment on module when it was previously imported Jul 19, 2016
Michael0x2a pushed a commit to Michael0x2a/mypy that referenced this issue Jul 19, 2016
Previously, the semantic analyzer seemed to always mark import symbols as
being of kind MODULE_REF during the third pass and did not preserve
whether the module was previously marked with the `# type: ignore`
comment or not.

This caused a contradiction in some cases when mypy was run in incremental
mode: suppose file a.py imported file b.py, and marked that import with the
ignore annotation.

Since the import is being ignored, mypy would not register that import
as a dependency, but since the import (during the previous run) was
marked as a MODULE_REF, mypy would attempt to load that module anyways
in some cases.

This commit fixes python#1904.
@gvanrossum
Copy link
Member

Could be caused by #1911?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants