[cfe-commits] [PATCH] Sema and AST for C++0x Lambda Expressions

[Douglas Gregor]

On Oct 17, 2011, at 9:30 AM, Douglas Gregor wrote:

> 
> On Oct 15, 2011, at 8:21 PM, John Freeman wrote:
> 
>>> +  /// Declaration for the closure type.
>>> +  CXXRecordDecl *ClosureType;
>>> 
>>> This is just getType()->getAsCXXRecordDecl(), no?
>> 
>> To my knowledge, yes it is. I added the ClosureType member simply for caching. I saw you removed it. The same could be done for the Function member as well. Is the general policy to keep the AST classes as small as possible?
> 
> Yes, absolutely. Memory footprint is extremely important when compiling C++ code, so we try to keep our data structures small. We'll use extra storage if it provides a significant performance improvement, of course, but that's not likely the case here.
> 
>>> +  /// The temporary object resulting from evaluating the lambda expression,
>>> +  /// represented by a call to the constructor of the closure type.
>>> +  CXXConstructExpr *ClosureObject;
>>> 
>>> This makes me think that LambdaExpr should just be a subclass of CXXConstructExpr, because there's a lot of behavior we get "for free" for lambdas if it derives from CXXConstructExpr (such as proper handling of the temporary). It would require some twisting-around of the logic for building lambda expressions (in particular, the LambdaExpr wouldn't be built until the whole body had been parsed), but I think the result would be better.
>> 
>> How should we store the bits and pieces up until the body has been parsed? Should there be a separate data structure just to hold them that gets passed between Sema functions, or should there be members within Sema for things like CurLambdaIntroducer and CurLambdaMethod, or something else?
> 
> 
> Check out BlockScopeInfo; you'll want something like that, to keep the stack of active lambdas available. It'll become extremely important once you start handling implicit captures.

FWIW, I hacked on your prior lambdas patch a bit to start adding a LambdaScopeInfo. I won't have any time to hack on lambdas further for quite a while, so I'm attaching the patch---in it's broken but perhaps instructive state---here.

	- Doug

-------------- next part --------------
A non-text attachment was scrubbed...
Name: lambdas.patch
Type: application/octet-stream
Size: 48058 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20111020/97197072/attachment.obj>