summaryrefslogtreecommitdiffstats
path: root/clang/test/Parser/objcxx0x-lambda-expressions.mm
Commit message (Collapse)AuthorAgeFilesLines
* N3922: direct-list-initialization of an auto-typed variable no longer deduces aRichard Smith2015-11-111-1/+1
| | | | | | | | | | | | | | | | | | | std::initializer_list<T> type. Instead, the list must contain a single element and the type is deduced from that. In Clang 3.7, we warned by default on all the cases that would change meaning due to this change. In Clang 3.8, we will support only the new rules -- per the request in N3922, this change is applied as a Defect Report against earlier versions of the C++ standard. This change is not entirely trivial, because for lambda init-captures we previously did not track the difference between direct-list-initialization and copy-list-initialization. The difference was not previously observable, because the two forms of initialization always did the same thing (the elements of the initializer list were always copy-initialized regardless of the initialization style used for the init-capture). llvm-svn: 252688
* Fix the end location of init-capture annotations in ObjC++Ben Langmuir2015-04-301-0/+13
| | | | | | | | | | | | | And thereby stop asserting. In ObjC++ modes, we tentatively parse the lambda introducer twice: once to disambiguate designators, which we also do in C++, and a second time to disambiguate objc message expressions. During the second tentative parse, the last cached token will be the annotation token we built in the first parse. So use getLastLoc() to get the correct end location for the rebuilt annotation. llvm-svn: 236246
* Add a warning for direct-list-initialization of a variable with a deduced typeRichard Smith2015-02-111-1/+1
| | | | | | | | (or of a lambda init-capture, which is sort-of such a variable). The semantics of such constructs will change when we implement N3922, so we intend to warn on this in Clang 3.6 then change the semantics in Clang 3.7. llvm-svn: 228792
* Add compat/extension warnings for init captures.Richard Smith2013-09-281-1/+1
| | | | llvm-svn: 191609
* 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