Thanks for explaining. I think the idea of handling the init-captures earlier is right, but I don't like the direction of creating the `VarDecl`s in the wrong context and patching them up later. Instead, can you:
* duplicate the `auto` deduction and handling of the initialization sequence for an //init-capture// into a separate `Sema` method (producing a type and an initializer expression and storing it on the `LambdaIntroducer`) * when parsing the //init-capture//, call that function straight away * likewise, when instantiating, do the same * push and pop an expression evaluation context around the parsing and instantiation of the lambda-introducer (we can't push one for each expression because ObjC disambiguation will get in the way, but fortunately we don't really need to do so) The variadic template part is a bit annoying. We want to track that we have entered the lexical context of a lambda (for variadic templates) but that we haven't entered its scope yet (for capturing); `CurLambdaInitCapture` feels like a hacky way to accomplish this. Instead, could we teach `tryCaptureVar` that a `LambdaScopeInfo` with a null `Lambda` pointer means that we've entered the lambda-introducer but not the lambda-body (and thus that `CapturingScopeInfo` entry should be skipped)? http://llvm-reviews.chandlerc.com/D2092 _______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
