summaryrefslogtreecommitdiffstats
path: root/clang/test/Parser/objcxx0x-lambda-expressions.mm
Commit message (Collapse)AuthorAgeFilesLines
* PR16094: I should have known Obj-C init-capture disambiguation couldn't beRichard Smith2013-05-211-3/+13
| | | | | | | | | | | | | | | | | | | | | *that* easy... Try a bit harder to disambiguate. This is mostly straightforward, but for =-style initializers, we actually need to know where an expression ends: [foo = bar baz] is a message send, whereas [foo = bar + baz] is a lambda-introducer. Handle this by parsing the expression eagerly, and replacing it with an annotation token. By chance, we use the *exact same* parsing rules in both cases (except that we need to assume we're inside a message send for the parse, to turn off various forms of inapplicable error recovery). llvm-svn: 182432
* First pass of semantic analysis for init-captures: check the initializer, buildRichard Smith2013-05-161-4/+4
| | | | | | | | | | | | | 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
* C++1y n3648: parse and reject init-captures for now.Richard Smith2013-05-091-0/+10
| | | | llvm-svn: 181553
* PR15132: Replace "address expression must be an lvalue or a functionRichard Smith2013-02-021-1/+1
| | | | | | | | | | | | | | designator" diagnostic with more correct and more human-friendly "cannot take address of rvalue of type 'T'". For the case of & &T::f, provide a custom diagnostic, rather than unhelpfully saying "cannot take address of rvalue of type '<overloaded function type>'". For the case of &array_temporary, treat it just like a class temporary (including allowing it as an extension); the existing diagnostic wording for the class temporary case works fine. llvm-svn: 174262
* Remove the "unsupported" error for lambda expressions. It's annoying,Douglas Gregor2012-02-091-6/+6
| | | | | | and rapidly becoming untrue. llvm-svn: 150165
* Fix yet one more testDouglas Gregor2012-02-091-1/+1
| | | | llvm-svn: 150129
* Refactor to share code for handling return statements between lambda ↵Eli Friedman2012-01-261-2/+1
| | | | | | expressions and block literals. As it turns out, almost all the logic can be shared. llvm-svn: 149031
* More lambda work: semantic analysis of capturing 'this'. It's a bit ↵Eli Friedman2012-01-071-1/+2
| | | | | | complicated, but we have to be careful about when exactly captures are marked given PotentiallyPotentiallyEvaluated contexts. (Actually, it's not 100% correct yet, but it's close enough for the moment.) llvm-svn: 147723
* More lambda work. Tweak the Sema interface slightly. Start adding the ↵Eli Friedman2012-01-051-4/+1
| | | | | | pieces to build the lambda class and its call operator. Create an actual scope for the lambda body. llvm-svn: 147595
* Stub out the Sema interface for lambda expressions, and change the parser to ↵Eli Friedman2012-01-041-6/+6
| | | | | | use it. Unconditionally error on lambda expressions because they don't work in any meaningful way yet. llvm-svn: 147515
* Update all tests other than Driver/std.cpp to use -std=c++11 rather thanRichard Smith2011-10-131-1/+1
| | | | | | -std=c++0x. Patch by Ahmed Charles! llvm-svn: 141900
* Parsing of C++0x lambda expressions, from John Freeman with help fromDouglas Gregor2011-08-041-0/+26
David Blaikie! llvm-svn: 136876
OpenPOWER on IntegriCloud