Closed katzdm closed 4 weeks ago
@llvm/issue-subscribers-clang-frontend
Author: Daniel M. Katz (katzdm)
Looks like this goes back to clang-13: https://godbolt.org/z/PMshGMY3E
It does not require -fblocks
if we use assertions build, they are usually more useful b/c they crash earlier and usually are closer to the core problem.
I haven’t tried messing with this yet, but this feels like it might be the issue: https://github.com/llvm/llvm-project/blob/9ec229dd3ede6368ee5fecf9b9731d8d21d8b1d2/clang/lib/Sema/SemaExpr.cpp#L16080-L16089
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 LambdaScopeInfo
’s flag to whatever value it had before the DiagnoseUnexpandedParameterPack()
call in here.
Actually, that would only return true
on error, so that doesn’t seem too plausible...
Oh wait, duh, I just confused myself: it does seem to happen here, it just returns false
because we’re in a lambda, so it’s fine, and we then crash later.
The following program produces an assert failure with a
clang
binary built with assertions, when compiled with-fblocks
:The assertion:
Here is another example that fails the same assertion:
Both have the same root cause:
CompoundStmt
body of the lambda, clang begins to parse^Ts
as aBlockExpr
.Sema::ActOnBlockArguments
function invokesDiagnoseUnexpandedParameterPacks
, which setsLambdaScopeInfo::ContainsUnexpandedParameterPacks
totrue
, prior to recognizing that theBlockExpr
is ill-formed.BlockExpr
is diagnosed, and is subsequently discarded from theCompoundStmt
representing the body of the lambda.LambdaScopeInfo
is used to initialize theLambdaExpr
, resulting inLambdaExpr::ContainsUnexpandedParameterPack
being set totrue
.LambdaExpr
becomes an argument to some other semantic construct (e.g.,StaticAssertDecl
,ParameterDecl
), whose semantic analysis callsDiagnoseUnexpandedParameterPack
.LambdaExpr
reports that it contains an unexpanded parameter pack, but the tree walk fails to find any pack (since the ill-formedBlockExpr
was discarded from theCompoundStmt
).Although I can imagine a few ways to patch this (e.g., keep an "error" representation of the ill-formed
BlockExpr
inCompoundStmt
, rollback the setting ofLambdaScopeInfo::ContainsUnexpandedParameterPack
when theBlockExpr
is 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.