summaryrefslogtreecommitdiffstats
path: root/clang/test/Parser/cxx0x-lambda-expressions.cpp
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
* 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
* Parse: Don't let BalancedDelimiterTracker consume cxx_defaultarg_endDavid Majnemer2015-01-121-0/+5
| | | | | | | | It is not correct to let it consume the cxx_defaultarg_end token. I'm starting to wonder if it makes more sense to stop SkipUntil from consuming such tokens. llvm-svn: 225615
* Parse: Don't parse beyond the end of the synthetic default argument tokDavid Majnemer2015-01-121-0/+5
| | | | | | | | Recovery from malformed lambda introducers would find us consuming the synthetic default argument token, which is bad. Instead, stop right before that token. llvm-svn: 225613
* Parse: Don't crash when trailing return type is missingDavid Majnemer2015-01-091-0/+7
| | | | | | | | | Sema::CheckParmsForFunctionDef can't cope with a null TypeSourceInfo. Don't let the AST contain the malformed lambda. This fixes PR22122. llvm-svn: 225505
* PR19339: Disambiguate lambdas with init-captures from designated initializersRichard Smith2014-04-131-1/+9
| | | | | | properly. llvm-svn: 206128
* Render anonymous entities as '(anonymous <thing>)' (and lambdas as '(lambda ↵David Blaikie2014-04-021-1/+1
| | | | | | | | | | | | at ... )') For namespaces, this is consistent with mangling and GCC's debug info behavior. For structs, GCC uses <anonymous struct> but we prefer consistency between all anonymous entities but don't want to confuse them with template arguments, etc, so we'll just go with parens in all cases. llvm-svn: 205398
* Allow GNU-style attributes on lambda expressions.Aaron Ballman2014-03-121-1/+7
| | | | llvm-svn: 203628
* Improving test coverage for lambda expressions with attribute specifiers.Aaron Ballman2014-03-111-1/+12
| | | | llvm-svn: 203602
* Changing this test case to use an unknown attribute, since there are not ↵Aaron Ballman2014-03-111-1/+1
| | | | | | currently any type attributes which would apply to a lambda, except in MSVC compatibility mode. llvm-svn: 203566
* Gracefully handle an attribute specifier following a lambda introducer when ↵Aaron Ballman2014-03-111-0/+1
| | | | | | the parameter list wasn't present. llvm-svn: 203565
* Add compat/extension warnings for init captures.Richard Smith2013-09-281-6/+6
| | | | llvm-svn: 191609
* Per latest drafting, switch to implementing init-captures as if by declaringRichard Smith2013-09-281-6/+4
| | | | | | and capturing a variable declaration, and complete the implementation of them. llvm-svn: 191605
* First pass of semantic analysis for init-captures: check the initializer, buildRichard Smith2013-05-161-9/+9
| | | | | | | | | | | | | 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/+18
| | | | llvm-svn: 181553
* Update regression tests for r166617.Eli Friedman2012-10-241-1/+1
| | | | llvm-svn: 166619
* PR13652: Don't assume the parameter array on a FunctionTypeLoc for a lambda willRichard Smith2012-08-301-0/+1
| | | | | | | be filled in; they won't if the lambda's declarator has an invalid type. Instead take the parameters from the declarator directly. llvm-svn: 162904
* In 'delete []', the '[]' never starts a lambda. Update a FIXME with a ↵Richard Smith2012-08-091-0/+7
| | | | | | standard reference and add a test. llvm-svn: 161604
* Fix parsing of trailing-return-type. Types are syntactically prohibited fromRichard Smith2012-03-121-1/+4
| | | | | | | | being defined here: [] () -> struct S {} does not define struct S. In passing, implement DR1318 (syntactic disambiguation of 'final'). llvm-svn: 152551
* Disambiguate between C++11 lambda expressions and C99 arrayDouglas Gregor2012-02-171-0/+11
| | | | | | | | | designators in the parser. In the worst case, this disambiguation requires tentative parsing just past the closing ']', but for most cases we'll be able to tell by looking ahead just one token (without going into the heavyweight tentative parsing machinery). llvm-svn: 150790
* Improve recovery for lambda expressions that have 'mutable' or aDouglas Gregor2012-02-161-0/+2
| | | | | | | trailing return type but not a '()'. Recover by inserting the parentheses. Thanks to Xeo on IRC for the example. llvm-svn: 150727
* Remove the "unsupported" error for lambda expressions. It's annoying,Douglas Gregor2012-02-091-7/+7
| | | | | | and rapidly becoming untrue. llvm-svn: 150165
* Fix tests for r150123Douglas Gregor2012-02-091-1/+1
| | | | llvm-svn: 150126
* Stub out the Sema interface for lambda expressions, and change the parser to ↵Eli Friedman2012-01-041-7/+7
| | | | | | use it. Unconditionally error on lambda expressions because they don't work in any meaningful way yet. llvm-svn: 147515
* Modify how the -verify flag works. Currently, the verification string andRichard Trieu2011-12-151-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | diagnostic message are compared. If either is a substring of the other, then no error is given. This gives rise to an unexpected case: // expect-error{{candidate function has different number of parameters}} will match the following error messages from Clang: candidate function has different number of parameters (expected 1 but has 2) candidate function has different number of parameters It will also match these other error messages: candidate function function has different number of parameters number of parameters This patch will change so that the verification string must be a substring of the diagnostic message before accepting. Also, all the failing tests from this change have been corrected. Some stats from this cleanup: 87 - removed extra spaces around verification strings 70 - wording updates to diagnostics 40 - extra leading or trailing characters (typos, unmatched parens or quotes) 35 - diagnostic level was included (error:, warning:, or note:) 18 - flag name put in the warning (-Wprotocol) llvm-svn: 146619
* 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/+27
David Blaikie! llvm-svn: 136876
OpenPOWER on IntegriCloud