Fix bug with dmypy not respecting @no_type_check after change in dependency#21626
Open
thomasbbrunner wants to merge 1 commit into
Open
Fix bug with dmypy not respecting @no_type_check after change in dependency#21626thomasbbrunner wants to merge 1 commit into
thomasbbrunner wants to merge 1 commit into
Conversation
Author
|
@ilevkivskyi I cannot assign a reviewer for this PR. What's the process here? Just wait for a contributor to pick this up? |
Contributor
|
According to mypy_primer, this change doesn't affect type check results on a corpus of open source code. ✅ |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Currently, in daemon mode, the body of a
@no_type_checkfunction 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:
b.SCALEtriggers a reprocess ofa.func. Even though the function is still decorated with@no_type_check, it gets type checked: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.