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.

Some other changes are required to keep things working as before because
of the assumption that ignored errors are never recorded.

This change will make an upcoming commit a little easier to read.

Before this change this method used an early-return approach.

We switch this for setting a variable and returning at the end.
To avoid changing the logic, we change some `if` statements into `elif`.

This change will simplify an upcoming commit where we inline this
into another method.

This new name reflects the name of the variable in the place where we
intend to inline this method.

This change allows us to alter the result of this logic so that it's
not simply boolean. That change will follow in another commit.

Before this change, this method was only called in one place, so it's
easy to in-line it.

Co-authored-by: David Seddon <david@seddonym.me>

The logic above has already ascertained that `info.blocker` is falsy, so
there's no point in checking that it's truthy now.

This call to `_add_error_info` tracks ignored lines to ensure dmypy
correctly finds errors when called multiple times.

This change will simplify the process of replacing `is_ignored_error`
with something more appropriate in an upcoming commit.

Co-authored-by: David Seddon <david@seddonym.me>

Before this change, we were recording errors when they were ignored
because their error code was not enabled.

This change ensures we only record enabled errors that are ignored.

Co-authored-by: David Seddon <david@seddonym.me>

These should now be faster, and will not require hacks to run
successfully on Windows.