Commit Graph

32 Commits

Author SHA1 Message Date
Marek Kurdej 0620e6f4b7 [clang] [C++2b] [P1102] Accept lambdas without parameter list ().
As an extension, accept such lambdas in previous standards with a warning.

* http://eel.is/c++draft/expr.prim.lambda
* http://wg21.link/P1102

Reviewed By: aaron.ballman

Differential Revision: https://reviews.llvm.org/D98433
2021-03-24 14:42:27 +01:00
Aaron Ballman b2bc0a3254 Implement P2173 for attributes on lambdas
https://wg21.link/P2173 is making its way through WG21 currently and
has not been formally adopted yet. This feature provides very useful
functionality in that you can specify attributes on the various
function *declarations* generated by a lambda expression, where the
current C++ grammar only allows attributes which apply to the various
function *types* so generated.

This patch implements P2173 on the assumption that it will be adopted
by WG21 with this syntax for C++23.
2021-03-03 10:05:39 -05:00
Richard Smith 5030928d60 [c++20] Implement semantic restrictions for C++20 designated
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
2019-08-30 22:52:55 +00:00
Erik Pilkington be19c48f6d [Parser] Lambda capture lists can start with '*'
Fixes llvm.org/PR42778

llvm-svn: 367346
2019-07-30 19:21:20 +00:00
Nicolas Lesser f53d172710 Added a better diagnostic when using the delete operator with lambdas
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
2019-05-19 15:07:58 +00:00
Richard Smith 42b1057244 N3922: direct-list-initialization of an auto-typed variable no longer deduces a
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
2015-11-11 01:36:17 +00:00
Richard Smith 215f423ff2 Add a warning for direct-list-initialization of a variable with a deduced type
(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
2015-02-11 02:41:33 +00:00
David Majnemer a3aef35d54 Parse: Don't let BalancedDelimiterTracker consume cxx_defaultarg_end
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
2015-01-12 03:14:18 +00:00
David Majnemer 89296ee2c3 Parse: Don't parse beyond the end of the synthetic default argument tok
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
2015-01-12 02:28:16 +00:00
David Majnemer e01c466c67 Parse: Don't crash when trailing return type is missing
Sema::CheckParmsForFunctionDef can't cope with a null TypeSourceInfo.
Don't let the AST contain the malformed lambda.

This fixes PR22122.

llvm-svn: 225505
2015-01-09 05:10:55 +00:00
Richard Smith 9e2f0a4f62 PR19339: Disambiguate lambdas with init-captures from designated initializers
properly.

llvm-svn: 206128
2014-04-13 04:31:48 +00:00
David Blaikie abe1a398e3 Render anonymous entities as '(anonymous <thing>)' (and lambdas as '(lambda 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
2014-04-02 05:58:29 +00:00
Aaron Ballman e8d69b7fc9 Allow GNU-style attributes on lambda expressions.
llvm-svn: 203628
2014-03-12 00:01:07 +00:00
Aaron Ballman 7e1fd018a8 Improving test coverage for lambda expressions with attribute specifiers.
llvm-svn: 203602
2014-03-11 20:32:35 +00:00
Aaron Ballman c6607cd2a1 Changing this test case to use an unknown attribute, since there are not currently any type attributes which would apply to a lambda, except in MSVC compatibility mode.
llvm-svn: 203566
2014-03-11 13:19:42 +00:00
Aaron Ballman b5c59f5862 Gracefully handle an attribute specifier following a lambda introducer when the parameter list wasn't present.
llvm-svn: 203565
2014-03-11 13:03:15 +00:00
Richard Smith 5b013f5050 Add compat/extension warnings for init captures.
llvm-svn: 191609
2013-09-28 05:38:27 +00:00
Richard Smith bb13c9a49d Per latest drafting, switch to implementing init-captures as if by declaring
and capturing a variable declaration, and complete the implementation of them.

llvm-svn: 191605
2013-09-28 04:02:39 +00:00
Richard Smith ba71c08523 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
2013-05-16 06:20:58 +00:00
Richard Smith 21b3ab43e1 C++1y n3648: parse and reject init-captures for now.
llvm-svn: 181553
2013-05-09 21:36:41 +00:00
Eli Friedman be20d43232 Update regression tests for r166617.
llvm-svn: 166619
2012-10-24 20:28:18 +00:00
Richard Smith b3afa6c483 PR13652: Don't assume the parameter array on a FunctionTypeLoc for a lambda will
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
2012-08-30 13:13:20 +00:00
Richard Smith 10c6072d61 In 'delete []', the '[]' never starts a lambda. Update a FIXME with a standard reference and add a test.
llvm-svn: 161604
2012-08-09 19:01:51 +00:00
Richard Smith bfdb108fc5 Fix parsing of trailing-return-type. Types are syntactically prohibited from
being defined here: [] () -> struct S {} does not define struct S.

In passing, implement DR1318 (syntactic disambiguation of 'final').

llvm-svn: 152551
2012-03-12 08:56:40 +00:00
Douglas Gregor a80cae11f6 Disambiguate between C++11 lambda expressions and C99 array
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
2012-02-17 03:49:44 +00:00
Douglas Gregor 6746c5d487 Improve recovery for lambda expressions that have 'mutable' or a
trailing return type but not a '()'. Recover by inserting the
parentheses. Thanks to Xeo on IRC for the example.

llvm-svn: 150727
2012-02-16 21:53:36 +00:00
Douglas Gregor 656bc62a73 Remove the "unsupported" error for lambda expressions. It's annoying,
and rapidly becoming untrue.

llvm-svn: 150165
2012-02-09 08:26:42 +00:00
Douglas Gregor 26f4b32f26 Fix tests for r150123
llvm-svn: 150126
2012-02-09 01:02:27 +00:00
Eli Friedman c7c97144af Stub out the Sema interface for lambda expressions, and change the parser to use it. Unconditionally error on lambda expressions because they don't work in any meaningful way yet.
llvm-svn: 147515
2012-01-04 02:40:39 +00:00
Richard Trieu 553b2b2e5d Modify how the -verify flag works. Currently, the verification string and
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
2011-12-15 00:38:15 +00:00
Richard Smith 9ca5c42582 Update all tests other than Driver/std.cpp to use -std=c++11 rather than
-std=c++0x. Patch by Ahmed Charles!

llvm-svn: 141900
2011-10-13 22:29:44 +00:00
Douglas Gregor db0b9f1264 Parsing of C++0x lambda expressions, from John Freeman with help from
David Blaikie!

llvm-svn: 136876
2011-08-04 15:30:47 +00:00