[cfe-dev] Lambda expr AST representation

[Abramo Bagnara]

Despite what is written in C++11 5.1.2p7:

The lambda-expression’s compound-statement yields the function-body
(8.4) of the function call operator, but for purposes of name lookup
(3.4), determining the type and value of this (9.3.2) and transforming
id-expressions referring to non-static class members into class member
access expressions using (*this) (9.3.1), the compound-statement is
considered in the context of the lambda-expression.

currently clang in its AST insert DeclRefExpr instead of correct
MemberExpr, as the following typescript shows:

$ cat p.cc
int f(int a) {
  return [a]()->int { return a; }();
}
$ _clang++ -cc1 -ast-dump -std=c++0x p.cc
typedef __int128 __int128_t;
typedef unsigned __int128 __uint128_t;
typedef __va_list_tag __builtin_va_list[1];
int f(int a) (CompoundStmt 0x4629a50 <p.cc:1:14, line:3:1>
  (ReturnStmt 0x4629a30 <line:2:3, col:35>
    (CXXOperatorCallExpr 0x46299b0 <col:10, col:35> 'int'
      (ImplicitCastExpr 0x4629998 <col:34, col:35> 'auto (*)(void) const
-> int' <FunctionToPointerDecay>
        (DeclRefExpr 0x4629910 <col:34, col:35> 'auto (void) const ->
int' lvalue CXXMethod 0x4629580 'operator()' 'auto (void) const -> int'))
      (ImplicitCastExpr 0x4629a18 <col:10, col:33> 'const class <lambda
at p.cc:2:10>' <NoOp>
        (LambdaExpr 0x4629748 <col:10, col:33> 'class <lambda at p.cc:2:10>'
          (ImplicitCastExpr 0x46296b0 <col:11> 'int' <LValueToRValue>
            (DeclRefExpr 0x4629688 <col:11> 'int' lvalue ParmVar
0x45fbf00 'a' 'int'))
          (CompoundStmt 0x4629728 <col:21, col:33>
            (ReturnStmt 0x4629708 <col:23, col:30>
              (ImplicitCastExpr 0x46296f0 <col:30> 'int' <LValueToRValue>
                (DeclRefExpr 0x46296c8 <col:30> 'const int' lvalue
ParmVar 0x45fbf00 'a' 'int')))))))))

Although I'm aware that these DeclRefExpr are handled especially in
CodeGen I think that this behavior should be considered a defect of AST.

Also, I've noted that lambda class fields generated for captured
variables are anonymous instead to have the name of the captured variable.

Do we agree that these two points should be fixed or there are reasons
I'm missing for current state?

-- 
Abramo Bagnara

BUGSENG srl - http://bugseng.com
mailto:abramo.bagnara at bugseng.com