python / python/mypy

Crash when packages and mypy_path discover one file under two module names

Open
#21,889 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

crash
Dominant language
Python
Stars
20.6k
Forks
3.3k
PR merge metrics
PR metrics pending

Description

Mypy crashes while reporting an ordinary type error when one physical package is discovered under two configured package roots. The existing duplicate-module diagnostic does not catch this packages + mypy_path configuration.

Minimal reproduction

Directory layout:

pyproject.toml
src/
  outer/
    __init__.py
    inner/
      example/
        __init__.py
        module.py

pyproject.toml:

[tool.mypy]
python_version = "3.14"
strict = true
mypy_path = ["src", "src/outer/inner"]
packages = ["outer", "example"]
explicit_package_bases = true

src/outer/inner/example/module.py:

def takes_int(value: int) -> None:
    pass


def broken() -> None:
    takes_int("not an int")

The __init__.py files are empty.

$ uv run --no-project --with mypy==2.3.1 mypy --no-incremental --show-traceback
src/outer/inner/example/module.py:6: error: Argument 1 to "takes_int" has incompatible type "str"; expected "int"  [arg-type]
.../src/outer/inner/example/module.py:6: error: INTERNAL ERROR -- Please try using mypy master on GitHub:
https://mypy.readthedocs.io/en/stable/common_issues.html#using-a-development-mypy-build
Please report a bug at https://github.com/python/mypy/issues
version: 2.3.1
.../src/outer/inner/example/module.py:6: note: use --pdb to drop into pdb
Traceback (most recent call last):
  File "mypy/checkexpr.py", line 6163, in accept
  File "mypy/checkexpr.py", line 499, in visit_call_expr
  File "mypy/checkexpr.py", line 630, in visit_call_expr_inner
  File "mypy/checkexpr.py", line 1498, in check_call_expr_with_callee_type
  File "mypy/checkexpr.py", line 1591, in check_call
  File "mypy/checkexpr.py", line 1873, in check_callable_call
  File "mypy/checkexpr.py", line 2762, in check_argument_types
  File "mypy/checkexpr.py", line 2799, in check_arg
  File "mypy/messages.py", line 812, in incompatible_argument
  File "mypy/messages.py", line 282, in fail
  File "mypy/messages.py", line 260, in report
  File "mypy/errors.py", line 680, in report
  File "mypy/errors.py", line 810, in add_error_info
  File "mypy/errors.py", line 684, in _add_error_info
    assert file not in self.flushed_files
AssertionError

Expected: report the ordinary arg-type error once, or reject the duplicate physical-file/module-name mapping with a useful diagnostic. Mypy should not crash.

This also reproduces on current master d32c4d38770745dd9fb6a0279204425e6070e6ad (2.4.0+dev.d32c4d).

Environment

  • macOS arm64
  • Python 3.14.7
  • mypy 2.3.1 compiled wheel

Prior issue search

This seems to be a similar underlying duplicate-file condition as #4881 and #7510, but both are closed because mypy added a "Source file found twice under different module names" diagnostic. That diagnostic does not prevent this configuration-driven variant in 2.3.1 or current master.

AI Disclosure

gpt-5.6-sol used to synthesize the minimal reproducer. I've reproduced this manually.

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Run the minimal reproduction with the stated packages and mypy_path settings, then trace the failure through errors.py at add_error_info/_add_error_info, using messages.py and checkexpr.py as the reported call path. Compare this with the existing duplicate-module diagnostic and add regression coverage. Done means the ordinary arg-type error is reported once or the duplicate mapping receives a useful diagnostic without an internal crash.

Written by the indexing model from the issue text.

Assessment

Tech stack
python
Domain
devtools
Issue type
Bug
Difficulty
4/5
Estimated time
3-5 days
Activity status
Active
Clarity
Clearly specified
Newbie friendliness
65/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.