[python] Pass the loop-carried arguments to a bare break or continue

[udsy19]

A break or continue written directly in a for body, rather than nested inside an if, emitted
its cc.break / cc.continue terminator with an empty operand list, so the kernel failed to
compile:

@cudaq.kernel
def bare_cont() -> int:
    r = 0
    for j in range(3):
        r = r + 1
        continue
    return r

error: 'cc.loop' op along control flow edge from Operation cc.continue to Region #2:
       region branch point has 0 operands, but region successor needs 1 inputs

RuntimeError: pass pipeline failed
RuntimeError: could not compile code for 'bare_cont..'.

The same happens for break, in nested loops, when iterating a qvector, and in purely quantum
kernels with no classical return value.

What this changes

Every terminator in a cc.loop body region has to forward that region's block arguments.
createForLoop establishes the invariant itself — the implicit fall-through terminator it appends
uses bodyBlock.arguments, and that is exactly the tuple pushForBodyStack records. The
isInIfStmtBlock() branch of visit_Break / visit_Continue already forwards it; only the other
branch hardcoded []. Hoisting the binding above the if and using it in both branches is a
net-zero-line change:

        # Get the innermost enclosing `for` or `while` loop
        inArgs = [b for b in self.inForBodyStack[-1]]
        if self.isInIfStmtBlock():
            cc.UnwindContinueOp(inArgs)
        else:
            cc.ContinueOp(inArgs)

The resulting terminator has the same shape python/tests/mlir/ast_break.py already asserts for the
if-nested path.

while loops are unaffected either way: visit_While builds the loop with no block arguments, so
the forwarded list is empty. I confirmed the printed module for a while loop with a bare
continue and with a bare break is byte-identical before and after this change, as is the module
for each of the two kernels the existing tests in these files already cover.

This is the same class of arity mismatch as #1682, fixed in #1693 — that fix corrected
inForBodyStack[0] → inForBodyStack[-1] in the isInIfStmtBlock() branch and left the other
branch emitting [].

Testing

python/tests/mlir/ast_break.py gains test_bare_break and python/tests/mlir/ast_continue.py
gains test_bare_continue, each a for loop whose break / continue is not nested in an if,
with a CHECK block in the files' existing style asserting the terminator now carries the
loop-carried operands. Both tests also invoke the kernel, exercising the JIT path that raised the
RuntimeError. Both fail before this change and pass after it.

There was no coverage of this branch before: both files place the statement under an if, and an
AST scan of python/ finds no @cudaq.kernel anywhere in the tree with a break or continue
that is not nested in an if.

Validation

The change was applied to the ast_bridge.py of an installed cudaq 0.15.1 wheel
(cuda_quantum_cu13, Python 3.13, macOS 26.5.1 arm64), exercised end to end, and the wheel restored
afterwards. Before, all eight for-loop forms failed to compile; after, every one matches CPython
(3, 1, 6, 2, 5, and the expected measurement distributions), and every case that worked
before is unchanged.

Fixes #5176

[copy-pr-bot]

This pull request requires additional validation before any workflows can run on NVIDIA's runners.

Pull request vetters can view their responsibilities here.

Contributors can view more details about this message here.

[schweitzpgi]

Yeah, that's a bug in the bridge. In fact, we should get rid of the premature optimizations in the bridge of it trying to thread variables around as values. The design is to have the compiler do that itself so it's done correctly.

[udsy19]

Thanks @schweitzpgi — and agreed on the larger point about the bridge threading values around. This PR does not touch that design; it only passes the loop-carried arguments that cc.BreakOp and cc.ContinueOp already require, so the emitted IR verifies instead of failing with "region branch point has 0 operands, but region successor needs 1 inputs".

CI has never run on it. Could you post /ok to test 031c1dce3ac2f94bb40dffbdaa6e174213d6f964 when you get a chance? And if you would rather fold this into a broader bridge cleanup, that is fine by me — happy to close it in favour of that.

---

[sacpis]

The CHECK lines expect the loop to carry two i64 values plus a cc.undef i64. The kernel in the test has no break, so the loop carries only the induction variable. The real IR is a single argument loop with no cc.undef.

Running the file's own RUN line fails.