AssertionError: Must not defer during final iteration & TypeError: '<' not supported between instances of 'ArgKind' and 'ArgKind' #14329
Labels
Comments
JukkaL
pushed a commit
that referenced
this issue
Jan 22, 2023
Ref #14329 This fixes one of the crashes reported in the issue. In fact, using recursive type caught this crash statically, plus another subtle crash in `snapshot_optional_type()`, _without a single false positive_ (I was able to cleanly type also symbol table snapshots, but decided it is not worth the churn since we only ever compare them with `==`, supported by ~every Python object). I feel triumphant :-)
JukkaL
pushed a commit
that referenced
this issue
Jan 23, 2023
Fixes #14329 This fixes the second crash reported in the issue (other one is already fixed). This one is tricky, it looks like it happens only when we bring in a new import cycle in an incremental update with `--follow-import=normal`. To explain the reason, a little reminder of how semantic analyzer passes work: * Originally, we recorded progress automatically when some new symbol was resolved and added to symbol tables. * With implementation of recursive types, this mechanism was insufficient, as recursive types require modifying some symbols _in place_, this is why `force_progress` flag was added to `defer()`. * I was only careful with this flag for recursive type aliases (that were implemented first), for other things (like recursive TypedDicts, etc) I just always passed `force_progress=True` (without checking if we actually resolved some placeholder types). * The reasoning for that is if we ever add `becomes_typeinfo=True`, there is no way this symbol will later be unresolved (otherwise how would we know this is something that is a type). * It turns out this reasoning doesn't work in some edge cases in daemon mode, we do put some placeholders with `becomes_typeinfo=True` for symbols imported from modules that were not yet processed, thus causing a crash (see test cases). * There were two options to fix this: one is to stop creating placeholders with `becomes_typeinfo=True` for unimported symbols in daemon mode, other one is to always carefully check if in-place update of a symbol actually resulted in progress. * Ultimately I decided that the first way is too fragile (and I don't understand how import following works for daemon anyway), and the second way is something that is technically correct anyway, so here is this PR I didn't add test cases for each of the crash scenarios, since they are all very similar. I only added two that I encountered "in the wild", upper bound and tuple base caused actual crash in `trio` stubs, plus also randomly a test for a TypedDict crash. _EDIT:_ and one more thing, the "cannot resolve name" error should never appear in normal mode, only in daemon update (see reasoning above), so I don't make those error messages detailed, just add some minimal info if we will need to debug them.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Crash Report
Basically, I am trying to program a game with the Trio asynchronous library. Using the mypy daemon and type checking different files makes it crash. Trying to make excerpt files for demonstrating the issue, I also found that I would encounter
AssertionError: Must not defer during final iterationif I had the setup slightly different.Traceback
If you type check
main.pyand then type checkwith_trio.py, you get this traceback from the log file:If you type check
with_trio.pyand then type checkmain.py, you get this traceback from the log file:To Reproduce
With the following files in a folder with nothing else
In
main.py:In
with_trio.py:In
recreate.sh:Assuming you don't already have a daemon running, Run
recreate.sh. There are more than onedmypy startcommand because it crashes in-between the two setups.Your Environment
trio==0.22.0
trio-typing==0.7.0
recreate.shfile for all daemon flagsmypy.ini(and other config files): No other configuration filesThe text was updated successfully, but these errors were encountered: