Nice, thanks! Normally we want to add a test verifying the optimization is working too. However, this is a special case --- just to let you know how the tracer currently works, we trace from backwards jumps. Once we see a for loop, we try "closing" the loop. Thus, we would never see _ITER_CHECK_TUPLE except for a nested for loop. However, since the inner loop will always warm up before the outer loop, it will be hard to extract the real trace we want to inspect.

In short, your testing code might look like this:

for i in range(WARMUP):
    for x in (1,2,3):
        pass

but that will generate 2 JIT executors, not just 1, so it will cause us some issues when trying to identify the jitted code.

This is more of a side ramble about the limitations of our testing infrastructure, nothing you can do to fix it till we fix the testing on our side.