The case generator tool may generate incorrect code for explicit gotos.

[markshannon]

Either the tool needs to reject all explicit gotos, or it needs to understand them.
Rejecting them all seems easier, and not that much of a burden on the user.

Example of incorrectly generated code: #102287

[gvanrossum]

It's not that simple. If the user code wants an error exit before it has DECREF'ed all its stack inputs, it must use goto error, otherwise the stack values are leaked. OTOH all error exits after the inputs have been DECREF'ed must use ERROR_IF(), else the values will be double-DECREF'ed.

In order to properly implement the behavior you ask for, the generator would have to understand all forms of DECREF, so it can track what is the correct way to exit. If we insist there are no "bare goto error" statements, we will need to rewrite ~50 instructions to get rid of those one way or another (probably inserting extra DECREFs).

(I counted and there are nearly 100 ERROR_IF() calls but nearly 50 goto error statements, in Python/bytecodes.c.)

[markshannon]

bytecodes.c now only contains gotos to a small set of special labels, which seems fine for correctness.
The only exception is CALL_LIST_APPEND which does its own refcount handling.
I think we can tolerate one special case.