[clang] Ill-formed block expressions within a lambda can yield assert-failures #109148
Assignees
Labels
clang:frontend
Language frontend issues, e.g. anything involving "Sema"
confirmed
Verified by a second party
consteval
C++20 consteval
crash
Prefer [crash-on-valid] or [crash-on-invalid]
lambda
C++11 lambda expressions
Comments
github-actions
bot
added
the
clang
EugeneZelenko
added
clang:frontend
|
@llvm/issue-subscribers-clang-frontend Author: Daniel M. Katz (katzdm)
The following program produces an assert failure with a `clang` binary built with assertions, when compiled with `-fblocks`:
template<typename... Ts>
struct Cls {
static_assert([] consteval -> void {
(^Ts);
});
};The assertion: Here is another example that fails the same assertion: template <typename... Ts>
void fn(int = [] consteval -> int { (^Ts); return 0; }());Both have the same root cause:
Although I can imagine a few ways to patch this (e.g., keep an "error" representation of the ill-formed |
|
Looks like this goes back to clang-13: https://godbolt.org/z/PMshGMY3E It does not require |
|
I haven’t tried messing with this yet, but this feels like it might be the issue: llvm-project/clang/lib/Sema/SemaExpr.cpp Lines 16080 to 16089 in 9ec229d We diagnose unexpanded parameter packs... and then promptly drop them. I think the ‘proper’ solution would be to resolve this fixme; This comment is from 2012, so maybe we can handle blocks with unexpanded paramter packs just fine now? I’ll try that, and if that doesn’t work, I think we can just reset the |
|
Actually, that would only return |
|
Oh wait, duh, I just confused myself: it does seem to happen here, it just returns |
Sirraide
added a commit
that referenced
this issue
Oct 11, 2024
#110762) Consider #109148: ```c++ template <typename ...Ts> void f() { [] { (^Ts); }; } ``` When we encounter `^Ts`, we try to parse a block and subsequently call `DiagnoseUnexpandedParameterPack()` (in `ActOnBlockArguments()`), which sees `Ts` and sets `ContainsUnexpandedParameterPack` to `true` in the `LambdaScopeInfo` of the enclosing lambda. However, the entire block is subsequently discarded entirely because it isn’t even syntactically well-formed. As a result, `ContainsUnexpandedParameterPack` is `true` despite the lambda’s body no longer containing any unexpanded packs, which causes an assertion the next time `DiagnoseUnexpandedParameterPack()` is called. This pr moves handling of unexpanded parameter packs into `CapturingScopeInfo` instead so that the same logic is used for both blocks and lambdas. This fixes this issue since the `ContainsUnexpandedParameterPack` flag is now part of the block (and before that, its `CapturingScopeInfo`) and no longer affects the surrounding lambda directly when the block is parsed. Moreover, this change makes blocks actually usable with pack expansion. This fixes #109148.
DanielCChen
pushed a commit
to DanielCChen/llvm-project
that referenced
this issue
Oct 16, 2024
llvm#110762) Consider llvm#109148: ```c++ template <typename ...Ts> void f() { [] { (^Ts); }; } ``` When we encounter `^Ts`, we try to parse a block and subsequently call `DiagnoseUnexpandedParameterPack()` (in `ActOnBlockArguments()`), which sees `Ts` and sets `ContainsUnexpandedParameterPack` to `true` in the `LambdaScopeInfo` of the enclosing lambda. However, the entire block is subsequently discarded entirely because it isn’t even syntactically well-formed. As a result, `ContainsUnexpandedParameterPack` is `true` despite the lambda’s body no longer containing any unexpanded packs, which causes an assertion the next time `DiagnoseUnexpandedParameterPack()` is called. This pr moves handling of unexpanded parameter packs into `CapturingScopeInfo` instead so that the same logic is used for both blocks and lambdas. This fixes this issue since the `ContainsUnexpandedParameterPack` flag is now part of the block (and before that, its `CapturingScopeInfo`) and no longer affects the surrounding lambda directly when the block is parsed. Moreover, this change makes blocks actually usable with pack expansion. This fixes llvm#109148.
bricknerb
pushed a commit
to bricknerb/llvm-project
that referenced
this issue
Oct 17, 2024
llvm#110762) Consider llvm#109148: ```c++ template <typename ...Ts> void f() { [] { (^Ts); }; } ``` When we encounter `^Ts`, we try to parse a block and subsequently call `DiagnoseUnexpandedParameterPack()` (in `ActOnBlockArguments()`), which sees `Ts` and sets `ContainsUnexpandedParameterPack` to `true` in the `LambdaScopeInfo` of the enclosing lambda. However, the entire block is subsequently discarded entirely because it isn’t even syntactically well-formed. As a result, `ContainsUnexpandedParameterPack` is `true` despite the lambda’s body no longer containing any unexpanded packs, which causes an assertion the next time `DiagnoseUnexpandedParameterPack()` is called. This pr moves handling of unexpanded parameter packs into `CapturingScopeInfo` instead so that the same logic is used for both blocks and lambdas. This fixes this issue since the `ContainsUnexpandedParameterPack` flag is now part of the block (and before that, its `CapturingScopeInfo`) and no longer affects the surrounding lambda directly when the block is parsed. Moreover, this change makes blocks actually usable with pack expansion. This fixes llvm#109148.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
The following program produces an assert failure with a
clangbinary built with assertions, when compiled with-fblocks:The assertion:
Here is another example that fails the same assertion:
Both have the same root cause:
CompoundStmtbody of the lambda, clang begins to parse^Tsas aBlockExpr.Sema::ActOnBlockArgumentsfunction invokesDiagnoseUnexpandedParameterPacks, which setsLambdaScopeInfo::ContainsUnexpandedParameterPackstotrue, prior to recognizing that theBlockExpris ill-formed.BlockExpris diagnosed, and is subsequently discarded from theCompoundStmtrepresenting the body of the lambda.LambdaScopeInfois used to initialize theLambdaExpr, resulting inLambdaExpr::ContainsUnexpandedParameterPackbeing set totrue.LambdaExprbecomes an argument to some other semantic construct (e.g.,StaticAssertDecl,ParameterDecl), whose semantic analysis callsDiagnoseUnexpandedParameterPack.LambdaExprreports that it contains an unexpanded parameter pack, but the tree walk fails to find any pack (since the ill-formedBlockExprwas discarded from theCompoundStmt).Although I can imagine a few ways to patch this (e.g., keep an "error" representation of the ill-formed
BlockExprinCompoundStmt, rollback the setting ofLambdaScopeInfo::ContainsUnexpandedParameterPackwhen theBlockExpris ill-formed, just remove the assertion fromDiagnoseUnexpandedParameterPacks), I'm not sure I love any of them. For now, I figured I'd just report the issue.The text was updated successfully, but these errors were encountered: