gh-152685: Apply PEP 479 to StopIteration thrown into a not-yet-started generator

[Joel-Wwalker]

gen.throw(StopIteration) on a generator that hasn't started yet lets the StopIteration escape unchanged instead of converting it to RuntimeError. A debug build trips the !PyErr_ExceptionMatches(PyExc_StopIteration) assert in gen_send_ex2; a release build silently violates PEP 479 (the issue shows a transaction manager committing where it should roll back).

Root cause: PEP 479 is implemented by a bytecode handler whose exception table covers the generator body but not the prologue. A generator created by RETURN_GENERATOR resumes at the following POP_TOP, so a throw into it faults at instr_ptr - 1, the RETURN_GENERATOR slot, before the handler's range. Extending the table doesn't work cleanly: the handler records one unwind depth, which differs between the prologue and the body (and between generator functions and generator expressions), and covering RETURN_GENERATOR would also cover it during the call that creates the generator.

Instead, convert at the point the exception would otherwise escape. When a generator frame propagates a StopIteration (or, for an async generator, a StopAsyncIteration), gen_send_ex2 raises RuntimeError with the original chained as cause and context, matching the in-body handler. This path is only reachable via the throw-into-unstarted case: a started generator's own handler converts first, and gen_close never enters an unstarted frame. Tests cover generators, generator expressions, coroutines, and async generators, and check that a non-StopIteration throw still propagates unchanged.

Fixes #152685

• Issue: Debug abort when calling <generator>.throw(StopIteration) on a generator that hasn't started yet #152685

[python-cla-bot]

All commit authors signed the Contributor License Agreement.