code objects remove unknown opcodes from the instruction stream when accessing `co_code`

[DinoV]

Bug report

Bug description:

If you construct a code object with an unknown opcode it'll get removed when the code object goes through the opcodes to de-opt them. We should just ignore unknown opcodes instead.

CPython versions tested on:

3.12, 3.14

Operating systems tested on:

Linux

Linked PRs

• gh-128045: Mark unknown opcodes as deopting to themselves #128044
• [3.14] gh-128045: Mark unknown opcodes as deopting to themselves (GH-128044) #134228
• gh-128045: Syncs w/ latest opcode metadata #134231

[markshannon]

Constructing a code object with an unknown opcode seems like a bug to me.

I presume this is for Cinder.
Is there a way to make this work for Cinder, without making CPython less resilient?

[DinoV]

The problem here is that this is related to our extension of the interpreter loop, so the opcodes are known to us, but unknown to the code object. I suppose we could open these tables up and allow someone to say "these are known opcodes" but I'm not sure that's an improvement.

Also we're not doing anything like "reject code objects with unknown opcodes", instead they're just silently turning into 0's which doesn't seem like it's being very resilient in the first place.