First pass of semantic analysis for init-captures: check the initializer, build

a FieldDecl from it, and propagate both into the closure type and the
LambdaExpr.

You can't do much useful with them yet -- you can't use them within the body
of the lambda, because we don't have a representation for "the this of the
lambda, not the this of the enclosing context". We also don't have support or a
representation for a nested capture of an init-capture yet, which was intended
to work despite not being allowed by the current standard wording.

llvm-svn: 181985

1 files changed, 4 insertions, 4 deletions

diff --git a/clang/test/Parser/objcxx0x-lambda-expressions.mm b/clang/test/Parser/objcxx0x-lambda-expressions.mm
index 94e47ccd3e0..b2a75f2edbb 100644
--- a/clang/test/Parser/objcxx0x-lambda-expressions.mm
+++ b/clang/test/Parser/objcxx0x-lambda-expressions.mm
@@ -18,10 +18,10 @@ class C {
     [=,&foo] () {}; 
     [this] () {}; 
 
-    [foo(bar)] () {}; // expected-error {{not supported}}
-    [foo = bar] () {}; // expected-error {{not supported}}
-    [foo{bar}] () {}; // expected-error {{not supported}}
-    [foo = {bar}] () {}; // expected-error {{not supported}}
+    [foo(bar)] () {};
+    [foo = bar] () {};
+    [foo{bar}] () {}; // expected-error {{<initializer_list>}}
+    [foo = {bar}] () {}; // expected-error {{<initializer_list>}}
 
     [foo(bar) baz] () {}; // expected-error {{called object type 'int' is not a function}}