Skip to content
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

Unexpected unused type ignore fix overrides #16675

Conversation

seddonym
Copy link

@seddonym seddonym commented Dec 18, 2023

This is a demo PR to support #15043.

It demonstrates how adding override decorators gets most of the newly failing tests passing (just look at the final commit).

Outstanding tests

FAILED mypy/test/testfinegrained.py::FineGrainedSuite::fine-grained.test::testRemovedModuleUnderIgnore
FAILED mypy/test/testfinegrained.py::FineGrainedSuite::fine-grained.test::testTypedDictCrashFallbackAfterDeletedMeet
FAILED mypy/test/testfinegrained.py::FineGrainedSuite::fine-grained.test::testTypedDictCrashFallbackAfterDeletedJoin

meshy and others added 8 commits October 4, 2023 22:18
This test currently fails with this error:

    AssertionError: Command 3 (dmypy check -- bar.py) did not give expected output
    --- Captured stderr call ---
    Expected:
      bar.py:2: error: Unused "type: ignore" comment (diff)
      == Return code: 1                              (diff)
    Actual:
      (empty)

It demonstrates a bug that when an module is removed using
`FineGrainedBuildManager.update` because it is not "seen" by
`fine_grained_increment_follow_imports`, then "unused type: ignore"
warnings disappear from subsequent checks.

Ref: python#9655
This test fails with the error:

    AssertionError: Command 3 (dmypy check -- bar.py) did not give expected output
    --- Captured stderr call ---
    Expected:
      bar.py:2: error: "type: ignore" comment without error code  [ignore-without-code] (diff)
      == Return code: 1                             (diff)
    Actual:
      (empty)

This test illustrates that '"type: ignore" comment without error code'
errors currently disappear in the same way that 'Unused "type: ignore"'
errors do as described in python#9655.

Ref: python#9655
This test fails with the error:

    AssertionError: Command 3 (dmypy check -- bar.py) did not give expected output
    --- Captured stderr call ---
    Expected:
      bar.py:4: error: Name "a" may be undefined  [possibly-undefined] (diff)
      == Return code: 1                             (diff)
    Actual:
      (empty)

This test illustrates that possibly-undefined errors currently disappear
in the same way that 'Unused "type: ignore"' errors do as described in python#9655.

Ref: python#9655
These tests show how some errors disappear on a re-run of dmypy after a
file is altered.
This which fixes issue
python#9655 wherein some types of error
would be lost when a file was re-processed by dmypy. Regression tests
are also included.

This also fixes another error where sometimes files would not be
re-processed by dmypy if the only error in the file was either "unused
type ignore" or "ignore without code".
This catches a regression caused by the previous commits where "type:
ignore" comments are erroneously marked as unused in re-runs of dmypy.

As far as I can tell, this only happens in modules which contain an
import that we don't know how to type (such as a module which does not
exist), and a submodule which is unused.
Before this change, fine-grained builds could spuriously mark ignored
legitimate errors as "unused ignores".

By keeping track of these ignored errors we ensure that enough analysis
is done to know that the ignored lines are actually useful.

We have to change is_errors_for_file so that we don't consider files as
faulty when all of their errors were hidden.
@seddonym seddonym closed this Dec 20, 2023
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 this pull request may close these issues.

2 participants