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
==

Riproduci il problema con lo scenario dmypy testBlockerBadBuild, quindi confrontalo con lo scenario equivalente di aggiornamento diretto di mypy mostrato nel report. Traccia l’effetto dell’errore di sintassi bloccante sulle esecuzioni successive di recheck o di aggiornamento; il lavoro è completato quando l’esecuzione finale non analizza il file a.py precedentemente escluso ed entrambe le riproduzioni hanno esito positivo.