================
@@ -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
_______________________________________________
cfe-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
