[cfe-commits] [PATCH] PR 12746: Code generation of variables reference expressions when mixing blocks and lambdas

[Douglas Gregor]

On May 8, 2012, at 6:18 PM, Meador Inge wrote:

> Hi All,
> 
> In PR 12746 a failing assertion was reported when mixing blocks and lambdas.
> The original reproduction case looked something like:
> 
> void foo(int *x)
> {
>  ^() {
>    [&]() {
>      return x == 0;
>    }();
>  }();
> }
> 
> The following assert in 'clang::CodeGenFunction::EmitDeclRefLValue' was failing
> because the variable declaration referenced in 'E' was not in the 'LocalDeclMap'
> and was not marked as referring to an enclosing local:
> 
>      assert(isa<BlockDecl>(CurCodeDecl) && E->refersToEnclosingLocal());
> 
> This problem has been fixed by ensuring that the 'DeclRefExpr' gets marked as
> referring to an enclosing local as it should be.
> 
> While investigating this issue I noticed that the reverse nesting fails too,
> but for a different reason:
> 
> void foo(int *x)
> {
>  [&]() {
>    ^() {
>      return x == 0;
>    }();
>  }();
> }
> 
> This time 'clang::CodeGen::CodeGenFunction::EmitBlockLiteral' goes to lookup
> the capture information for the nested parameter 'x', but crashes because it
> is actually nested in a lambda and the  'BlockInfo' is NULL.  This was fixed by
> adding a check to ensure 'BlockInfo' is not NULL.
> 
> OK?

I simplified the patch a bit and committed as r156925/156926. Essentially, we can compute whether the DeclRefExpr refers to an enclosing local directly in tryCaptureVariable, so it doesn't need to be passed down.

Also, I moved the new test cases into the appropriate place (test/CXX/expr/expr.prim/expr.prim.lambda) and turned them into tests of IR generation, since the normal "-verify" only does semantic analysis.

Thank you!

	- Doug