[clang] Accept lambdas in C++03 as an extensions (#73376)

Implements
https://discourse.llvm.org/t/rfc-allow-c-11-lambdas-in-c-03-as-an-extension/75262

[clang] Use -std=c++23 instead of -std=c++2b

During the ISO C++ Committee meeting plenary session the C++23 Standard
has been voted as technical complete.

This updates the reference to c++2b to c++

[clang] Use -std=c++23 instead of -std=c++2b

During the ISO C++ Committee meeting plenary session the C++23 Standard
has been voted as technical complete.

This updates the reference to c++2b to c++23 and updates the __cplusplus
macro.

Drive-by fixes c++1z -> c++17 and c++2a -> c++20 when seen.

Reviewed By: aaron.ballman

Differential Revision: https://reviews.llvm.org/D149553

show more ...

[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.

[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

show more ...

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 t

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.

show more ...

[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

[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

show more ...

[Parser] Lambda capture lists can start with '*'

Fixes llvm.org/PR42778

llvm-svn: 367346

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 []() { ret

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

show more ...

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 C

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

show more ...

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 im

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

show more ...

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 SkipUnti

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

show more ...

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. Instea

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

show more ...

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.

ll

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

show more ...

PR19339: Disambiguate lambdas with init-captures from designated initializers
properly.

llvm-svn: 206128

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 <anonymou

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

show more ...

Allow GNU-style attributes on lambda expressions.

llvm-svn: 203628

Improving test coverage for lambda expressions with attribute specifiers.

llvm-svn: 203602

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

Gracefully handle an attribute specifier following a lambda introducer when the parameter list wasn't present.

llvm-svn: 203565

Add compat/extension warnings for init captures.

llvm-svn: 191609

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

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 y

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

show more ...

C++1y n3648: parse and reject init-captures for now.

llvm-svn: 181553

Update regression tests for r166617.

llvm-svn: 166619

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 declarat

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

show more ...

In 'delete []', the '[]' never starts a lambda. Update a FIXME with a standard reference and add a test.

llvm-svn: 161604