mypy icon indicating copy to clipboard operation
mypy copied to clipboard

`--disable-error-code=unused-ignore` should override `enable_error_code = ["unused-ignore"]`

Open bersbersbers opened this issue 1 month ago • 4 comments

Bug Report

mypy bug.py --disable-error-code=unused-ignore shows

bug.py:1: error: Unused "type: ignore" comment [unused-ignore] Found 1 error in 1 file (checked 1 source file)

To Reproduce

bug.py

a = 1  # type:ignore[comparison-overlap]

pyproject.toml

[tool.mypy]
enable_error_code = ["unused-ignore"]

Expected Behavior

No error. IMHO, command-line settings should override settings file.

Actual Behavior

See above

Your Environment

  • Mypy version used: 1.19.0
  • Mypy command-line flags: see above
  • Mypy configuration options from mypy.ini (and other config files): see above
  • Python version used: 3.14.0

bersbersbers avatar Dec 02 '25 04:12 bersbersbers

Yep, https://mypy.readthedocs.io/en/stable/config_file.html#config-file-format ("When options conflict, the precedence order...") specifies that command line options should overrule top-level configuration file options. I haven't looked into this further.

wyattscarpenter avatar Dec 02 '25 06:12 wyattscarpenter

Confirmed. It is common knowledge that CLI flags override envvars, and those in turn override configuration file entries (local, then user-level, then global).

This is not specific to --{en,dis}able-error-code, possibly-undefined suffers from the same problem:

$ mypy -c $'if 1:a = 1\nprint(a)' --cache-dir=/dev/null
Success: no issues found in 1 source file
$ cat <<EOF >pyproject.toml
[tool.mypy]
enable_error_code = ["possibly-undefined"]
EOF
$ mypy -c $'if 1:a = 1\nprint(a)' --cache-dir=/dev/null
<string>:2: error: Name "a" may be undefined  [possibly-undefined]
Found 1 error in 1 file (checked 1 source file)
$ mypy -c $'if 1:a = 1\nprint(a)' --disable-error-code=possibly-undefined --cache-dir=/dev/null
<string>:2: error: Name "a" may be undefined  [possibly-undefined]
Found 1 error in 1 file (checked 1 source file)

Probably all codes that are disabled by default are affected.

The ultimate issue is that enable-error-code has lower priority than disable-error-code, so two strategies clash: --disable-error-code should have higher priority because it is passed as argv, but lower priority because we declare so:

Note: This flag will override disabled error codes from the --disable-error-code flag.

So if both were provided by the same means (both as CLI flags or both as config file entries), this behaviour would be sound, but not when the priority is clear from the source.

sterliakov avatar Dec 02 '25 22:12 sterliakov

Hi! I’m a first-time contributor and I’d like to work on fixing this issue. Would adjusting the precedence logic in the CLI/config parser and adding tests to ensure that command-line flags correctly override configuration be an okay approach for me to take on?

franzengel04 avatar Dec 02 '25 22:12 franzengel04

@franzengel04 thanks! Yes, that sounds good to me:)

sterliakov avatar Dec 02 '25 22:12 sterliakov