Repository navigation
Find a way to handle branch events in async for #128534
Description
Activity
The bytecode for
async def foo(x): async for y in x: A
is
1 RETURN_GENERATOR POP_TOP L1: RESUME 0 2 LOAD_FAST 0 (x) GET_AITER L2: GET_ANEXT LOAD_CONST 0 (None) L3: SEND 3 (to L6) L4: YIELD_VALUE 1 L5: RESUME 3 JUMP_BACKWARD_NO_INTERRUPT 5 (to L3) L6: END_SEND L7: STORE_FAST 1 (y) 3 LOAD_GLOBAL 0 (A) POP_TOP JUMP_BACKWARD 17 (to L2) 2 L8: CLEANUP_THROW L9: JUMP_BACKWARD_NO_INTERRUPT 12 (to L6) L10: END_ASYNC_FOR LOAD_CONST 0 (None) RETURN_VALUE -- L11: CALL_INTRINSIC_1 3 (INTRINSIC_STOPITERATION_ERROR) RERAISE 1 ExceptionTable: L1 to L2 -> L11 [0] lasti L2 to L4 -> L10 [1] L4 to L5 -> L8 [3] L5 to L7 -> L10 [1] L7 to L8 -> L11 [0] lasti L8 to L9 -> L10 [1] L10 to L11 -> L11 [0] lastiOne way to instrument this would be to add a
NOT_TAKENafter theEND_SENDor instrument theEND_SENDfor theLEFTbranch, For theRIGHTbranch we could instrumentEND_ASYNC_FOR.
This shouldn't prevent future specialization ofasync foras that would require splittingEND_ASYNC_FORinto two instructions. We would then instrument the second.We still need to add these new branches to
co_branches()
When instrumenting regular
forloops, we instrument theFOR_ITERinstruction as theLEFTbranch and thePOP_ITERinstruction as theRIGHTbranch.This doesn't work for
async foras it uses exceptions to exit the loop.Raising an exception is the documented behavior for exiting a [async] generator, so we will still need to generate an event for the exception being raised, much as we do in
INSTRUMENTED_END_FORas well as theBRANCHevents.Linked PRs
async forloops. #130569async for#130847