Fix bug with dmypy not respecting @no_type_check after change in dependency

[thomasbbrunner]

Currently, in daemon mode, the body of a @no_type_check function is type-checked anyway when the function is reprocessed because a type-check-dependency changed. This is even the case if the @no_type_check function isn't changed at all.

This leads to false positives, where mypy flags typing issues in a function that is not supposed to be type checked.

Other similar typing decorators are already correctly handled in the code. In this PR, I'm proposing to do the same for typing.no_type_check.

Moreover, this adds a fine-grained regression test.

Reproduction

To reproduce the bug described above:

1. Create two local files:

# a.py
from typing import no_type_check
from b import SCALE

  @no_type_check
  def func() -> None:
      factor: int = SCALE
      bad: int = "definitely not an int"

# b.py
SCALE: int = 3

2. Run the daemon:

> dmypy run -- --check-untyped-defs a.py b.py
Success: no issues found in 2 source files

3. Edit only b.py, flipping the type of SCALE:

# b.py
SCALE: str = "3"

4. Re-run the same daemon. The changed type of b.SCALE triggers a reprocess of a.func. Even though the function is still decorated with @no_type_check, it gets type checked:

> dmypy run -- --check-untyped-defs a.py b.py
a.py:8: error: Incompatible types in assignment (expression has type "str", variable has type "int")  [assignment]
a.py:9: error: Incompatible types in assignment (expression has type "str", variable has type "int")  [assignment]
Found 2 errors in 1 file (checked 2 source files)

5. This only happens in incremental mode. A cold daemon shows no errors:

> dmypy stop && dmypy run -- --check-untyped-defs a.py b.py
Success: no issues found in 2 source files

Disclaimer

I've read the contributor guide. This was really hard to debug, so I've employed an LLM to come up with a reproduction, find the bug in the mypy codebase and implement a fix. I've reviewed the generated code and I'm happy with its quality. Happy to iterate over the code.

[thomasbbrunner]

@ilevkivskyi I cannot assign a reviewer for this PR. What's the process here? Just wait for a contributor to pick this up?

[github-actions]

According to mypy_primer, this change doesn't affect type check results on a corpus of open source code. ✅

[thomasbbrunner]

We keep hitting this issue in our codebases, would be great to get the fix merged.

What's the process for getting an MR reviewed?

cc @JukkaL @p-sawicki

[ilevkivskyi]

As per our policy we don't accept LLM generated PRs from new contributors.

[thomasbbrunner]

As per our policy we don't accept LLM generated PRs from new contributors.

This is not what your contributor's guide says (I read it before submitting this PR). If this is your policy in practice, you should update the guide. I wouldn't have bothered with this PR if I knew this.

This is not a "Claude, find a bug and submit" type of PR. This is a bug my team and I face every day in our codebase. I vouch for the code here and the repro is clear.

Either way, it seems there's no interest in fixing this, which is yet another reason for us to migrate to a different type checker.