[clang] [clang][AST] Fix crash on labeled break/continue within switch condition statement expression (PR #228655)

via cfe-commits cfe-commits at lists.llvm.org
Sat Oct 10 09:54:32 PDT 2026


================
@@ -7196,6 +7196,9 @@ bool Compiler<Emitter>::visitBreakStmt(const BreakStmt *S) {
       }
     }
   } else {
+    const Stmt *TargetLoop = S->getNamedLoopOrSwitch();
+    assert(TargetLoop && "break target label not available");
----------------
Expertcoderz wrote:

> Can you see what happens if you write:

With `-fno-experimental-new-constant-interpreter` the resulting IR for `f()` looks like this:

```ll
define dso_local void @f() #0 {
entry:
  br label %foo

foo:                                              ; preds = %entry
  br label %for.cond

for.cond:                                         ; preds = %for.cond, %foo
  br label %for.cond
}
```

There's no diagnostic at all and it seems not to be breaking out of the `foo`-labeled loop, so there's definitely something wrong here.

On the other hand, with the new constant interpreter, it triggers the assertion on the line that you commented. I agree with you that there's an issue with how the labeled `break`/`continue`s are being wrongly treated as unnamed `break`/`continue` in both of these cases.

(Fix incoming!)

> I’d imagine the error could be something like ‘cannot break/continue to label '%0' that is not inside the current evaluation context’ or however we typically phrase that.

Is this referring to the *"'break/continue' label does not name an enclosing loop"* diagnostic? If so, I'll see if it can be emitted in place of the default *"constexpr variable 'x' must be initialized by a constant"* that usually happens when evaluation fails, since the former is more specific about the problem.

> From what I can tell, in all of your test cases, there isn’t actually a loop inside the evaluated expression, so evaluation fails because it can’t find an enclosing loop, not because the `break` is invalid

Yep, I'll be adding further test cases to cover this kind of situation. Thanks for informing me of the oversight!

https://github.com/llvm/llvm-project/pull/228655


More information about the cfe-commits mailing list