Original issue: mypyc/mypyc#1131

I have been encountering this error during builds:

Traceback (most recent call last):
  File "/xxx/xxx/setup.py", line 37, in <module>
    ext_modules=mypycify(...),
                ^^^^^^^^^^^^^
  File "mypyc/build.py", line 549, in mypycify
  File "mypyc/build.py", line 447, in mypyc_build
  File "mypyc/build.py", line 245, in generate_c
  File "mypyc/codegen/emitmodule.py", line 448, in compile_modules_to_c
  File "mypyc/codegen/emitmodule.py", line 329, in compile_ir_to_c
  File "mypyc/codegen/emitmodule.py", line 573, in generate_c_for_modules
  File "mypyc/codegen/emitfunc.py", line 178, in generate_native_function
  File "mypyc/ir/ops.py", line 804, in accept
  File "mypyc/codegen/emitfunc.py", line 396, in visit_get_attr
  File "mypyc/codegen/emit.py", line 416, in emit_undefined_attr_check
ValueError: value is not in list

The error is curiously non-deterministic. It will often occur, but sometimes it will not, indicating some sort of undefined iteration order makes it show up or skips it.

While trying to hunt it down, I have noticed constructs like these in my code-base influence its appearance:

• base class defines self._myvar
• subclass writes to self._myvar -> error
• subclass calls function in base class that updates self._myvar -> OK

Unfortunately after a number of attempts, I have not actually been able to isolate a test-case, so there is more involved than the example above. My code uses multiple inheritance with traits so that may also be relevant. The issue appears on my own code-base pretty reliably. The first build attempt generally fails for me, but when doing repeated runs on the same unmodified code, within 5 attempts, I usually reach a working build.

This PR fixes the issue reliably for me, and it certainly looks to me as if the replaced code was a bug. I have now tested over 50 build rounds on my code-base without a single failure.

The full test suite completes without errors locally with this change, CPython 3.12.10.

Even without a test-case, if it can be confirmed the original code was wrong, this should be a mergeable PR.