summaryrefslogtreecommitdiffstats
path: root/clang/test/Parser/cxx0x-lambda-expressions.cpp
Commit message (Collapse)AuthorAgeFilesLines
* [c++20] Implement semantic restrictions for C++20 designatedRichard Smith2019-08-301-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | initializers. This has some interesting interactions with our existing extensions to support C99 designated initializers as an extension in C++. Those are resolved as follows: * We continue to permit the full breadth of C99 designated initializers in C++, with the exception that we disallow a partial overwrite of an initializer with a non-trivially-destructible type. (Full overwrite is OK, because we won't run the first initializer at all.) * The C99 extensions are disallowed in SFINAE contexts and during overload resolution, where they could change the meaning of valid programs. * C++20 disallows reordering of initializers. We only check for that for the simple cases that the C++20 rules permit (designators of the form '.field_name =' and continue to allow reordering in other cases). It would be nice to improve this behavior in future. * All C99 designated initializer extensions produce a warning by default in C++20 mode. People are going to learn the C++ rules based on what Clang diagnoses, so it's important we diagnose these properly by default. * In C++ <= 17, we apply the C++20 rules rather than the C99 rules, and so still diagnose C99 extensions as described above. We continue to accept designated C++20-compatible initializers in C++ <= 17 silently by default (but naturally still reject under -pedantic-errors). This is not a complete implementation of P0329R4. In particular, that paper introduces new non-C99-compatible syntax { .field { init } }, and we do not support that yet. This is based on a previous patch by Don Hinton, though I've made substantial changes when addressing the above interactions. Differential Revision: https://reviews.llvm.org/D59754 llvm-svn: 370544
* [Parser] Lambda capture lists can start with '*'Erik Pilkington2019-07-301-0/+13
| | | | | | Fixes llvm.org/PR42778 llvm-svn: 367346
* Added a better diagnostic when using the delete operator with lambdasNicolas Lesser2019-05-191-10/+37
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This adds a new error for missing parentheses around lambdas in delete operators. ``` int main() { delete []() { return new int(); }(); } ``` This will result in: ``` test.cpp:2:3: error: '[]' after delete interpreted as 'delete[]' delete []() { return new int(); }(); ^~~~~~~~~ test.cpp:2:9: note: add parentheses around the lambda delete []() { return new int(); }(); ^ ( ) ``` Reviewers: rsmith Reviewed By: rsmith Subscribers: riccibruno, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D36357 llvm-svn: 361119
* 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