Daemon can lose updates if there is a blocking error in intermediate run

Inline options parsing causes files to force-included in the build if they were previously excluded. For example this test fails with "Unrecognized option..." on the last run:

[case testBlockerBadBuild]
$ dmypy start -- --follow-imports=skip
Daemon started
$ dmypy check a.py
a.py:1: error: Unsupported operand types for + ("int" and "str")
== Return code: 1
$ {python} -c "import shutil; shutil.copy('a.py.2', 'a.py')"
$ dmypy recheck --update b.py --remove a.py
b.py:1: error: invalid syntax
== Return code: 1
$ dmypy recheck --update c.py --remove b.py

[file a.py]
42 + 'no'

[file a.py.2]
# mypy: why-is-this-file-checked-again
42 + 'no'

[file b.py]
syntax error

[file c.py]
# OK

In fact, a.py shouldn't be even parsed on the last run. Note that it is actually correctly not parsed if the error on the second run is non-blocking (like 42 + 'no').

Note that exactly the same problem appears if update is called directly, this test equally fails with same symptoms:

[case testBlockerBadBuild]
# flags: --follow-imports=skip
# cmd: mypy a.py
# cmd2: mypy b.py
# cmd3: mypy c.py

[file a.py]
# OK

[file b.py.2]
syntax error here

[file c.py.3]
# OK

[file a.py.3]
# mypy: this-file-is-not-in-build-in-cmd3-why-is-it-checked

[out]
==
b.py:1: error: invalid syntax
==

dmypy の testBlockerBadBuild シナリオで問題を再現し、その後、レポートに示されている同等の直接 mypy 更新シナリオと比較します。ブロッキング構文エラーが後続の recheck または更新の実行にどのような影響を与えるかを追跡します。完了条件は、最終実行で以前除外されていた a.py をパースせず、両方の再現が成功することです。