Repository navigation
Find a way to handle branch events in async for #128534
Description
When instrumenting regular for loops, we instrument the FOR_ITER instruction as the LEFT branch and the POP_ITER instruction as the RIGHT branch.
This doesn't work for async for as 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_FOR as well as the BRANCH events.
Activity
markshannon commented on Jan 6, 2025
The bytecode for
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_TAKEN after the END_SEND or instrument the END_SEND for the LEFT branch, For the RIGHT branch we could instrument END_ASYNC_FOR.
This shouldn't prevent future specialization of async for as that would require splitting END_ASYNC_FOR into two instructions. We would then instrument the second.
GH-128534: Instrument branches for `async for` loops. (GH-130569)
markshannon commented on Mar 3, 2025
We still need to add these new branches to co_branches()
GH-128534: Fix behavior of branch monitoring for `async for` (GH-130847)