[clang] Avoid -Wshadow warning when init-capture named same as class field (#74512)

Shadowing warning doesn't make much sense since field is not available
in lambda's body without capturing this.

[clang] Avoid -Wshadow warning when init-capture named same as class field (#74512)

Shadowing warning doesn't make much sense since field is not available
in lambda's body without capturing this.

Fixes https://github.com/llvm/llvm-project/issues/71976

show more ...

[clang][Sema] `-Wshadow` warns about shadowings by static local variables

This patch makes `-Wshadow` warn about the shadowings by static local variables.

Fixes https://github.com/llvm/llvm-project

[clang][Sema] `-Wshadow` warns about shadowings by static local variables

This patch makes `-Wshadow` warn about the shadowings by static local variables.

Fixes https://github.com/llvm/llvm-project/issues/62850
Differential Revision: https://reviews.llvm.org/D151214

show more ...

[clang] Diagnose shadowing of lambda's template parameter by a capture

expr.prim.lambda.capture p5 says:
If an identifier in a capture appears as the declarator-id of a parameter of
the lambda-decla

[clang] Diagnose shadowing of lambda's template parameter by a capture

expr.prim.lambda.capture p5 says:
If an identifier in a capture appears as the declarator-id of a parameter of
the lambda-declarator's parameter-declaration-clause or as the name of a
template parameter of the lambda-expression's template-parameter-list,
the program is ill-formed.
and also has the following example:
```
auto h = [y = 0]<typename y>(y) { return 0; };
```
which now results in
```
error: declaration of 'y' shadows template parameter
auto l1 = [y = 0]<typename y>(y) { return 0; };
^
note: template parameter is declared here
auto l1 = [y = 0]<typename y>(y) { return 0; };
^
```

Fixes https://github.com/llvm/llvm-project/issues/61105

Reviewed By: shafik, cor3ntin

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

show more ...

[Clang] Implement Change scope of lambda trailing-return-type

This implements P2036R3 and P2579R0.
That is, explicit, int, and implicit capture become visible
at the start of the parameter head.

Re

[Clang] Implement Change scope of lambda trailing-return-type

This implements P2036R3 and P2579R0.
That is, explicit, int, and implicit capture become visible
at the start of the parameter head.

Reviewed By: aaron.ballman, rupprecht, shafik

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

show more ...

Revert "[Clang] Implement Change scope of lambda trailing-return-type"

This reverts commit d708a186b6a9b050d09558163dd353d9f738c82d (and typo fix e4bc9898ddbeb70bc49d713bbf863f050f21e03f). It causes

Revert "[Clang] Implement Change scope of lambda trailing-return-type"

This reverts commit d708a186b6a9b050d09558163dd353d9f738c82d (and typo fix e4bc9898ddbeb70bc49d713bbf863f050f21e03f). It causes a compilation error for this:

```
struct StringLiteral {
template <int N>
StringLiteral(const char (&array)[N])
__attribute__((enable_if(N > 0 && N == __builtin_strlen(array) + 1,
"invalid string literal")));
};

struct Message {
Message(StringLiteral);
};

void Func1() {
auto x = Message("x"); // Note: this is fine

// Note: "xx\0" to force a different type, StringLiteral<3>, otherwise this
// successfully builds.
auto y = [&](decltype(Message("xx"))) {};

// ^ fails with: repro.cc:18:13: error: reference to local variable 'array'
// declared in enclosing function 'StringLiteral::StringLiteral<3>'

(void)x;
(void)y;
}
```

More details posted to D124351.

show more ...

[Clang] Implement Change scope of lambda trailing-return-type

This implements P2036R3 and P2579R0.
That is, explicit, int, and implicit capture become visible
at the start of the parameter head.

Re

[Clang] Implement Change scope of lambda trailing-return-type

This implements P2036R3 and P2579R0.
That is, explicit, int, and implicit capture become visible
at the start of the parameter head.

Reviewed By: aaron.ballman

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

show more ...

Revert D119136 "[clang] Implement Change scope of lambda trailing-return-type" and its follow-up

This reverts commit 69dd89fdcbd846375a45e2fe3a88710887236d7a.
This reverts commit 04000c2f928a7adc321

Revert D119136 "[clang] Implement Change scope of lambda trailing-return-type" and its follow-up

This reverts commit 69dd89fdcbd846375a45e2fe3a88710887236d7a.
This reverts commit 04000c2f928a7adc32138a664d167f01b642bef3.

The current states breaks libstdc++ usage (https://reviews.llvm.org/D119136#3455423).
The fixup has been reverted as it caused other valid code to be disallowed.
I think we should start from the clean state by reverting all relevant commits.

show more ...

[clang] Implement Change scope of lambda trailing-return-type

Implement P2036R3.

Captured variables by copy (explicitely or not), are deduced
correctly at the point we know whether the lambda is mu

[clang] Implement Change scope of lambda trailing-return-type

Implement P2036R3.

Captured variables by copy (explicitely or not), are deduced
correctly at the point we know whether the lambda is mutable,
and ill-formed before that.

Up until now, the entire lambda declaration up to the start of the body would be parsed in the parent scope, such that capture would not be available to look up.

The scoping is changed to have an outer lambda scope, followed by the lambda prototype and body.

The lambda scope is necessary because there may be a template scope between the start of the lambda (to which we want to attach the captured variable) and the prototype scope.

We also need to introduce a declaration context to attach the captured variable to (and several parts of clang assume captures are handled from the call operator context), before we know the type of the call operator.

The order of operations is as follow:

* Parse the init capture in the lambda's parent scope

* Introduce a lambda scope

* Create the lambda class and call operator

* Add the init captures to the call operator context and the lambda scope. But the variables are not capured yet (because we don't know their type).
Instead, explicit captures are stored in a temporary map that conserves the order of capture (for the purpose of having a stable order in the ast dumps).

* A flag is set on LambdaScopeInfo to indicate that we have not yet injected the captures.

* The parameters are parsed (in the parent context, as lambda mangling recurses in the parent context, we couldn't mangle a lambda that is attached to the context of a lambda whose type is not yet known).

* The lambda qualifiers are parsed, at this point We can switch (for the second time) inside the lambda context, unset the flag indicating that we have not parsed the lambda qualifiers,
record the lambda is mutable and capture the explicit variables.

* We can parse the rest of the lambda type, transform the lambda and call operator's types and also transform the call operator to a template function decl where necessary.

At this point, both captures and parameters can be injected in the body's scope. When trying to capture an implicit variable, if we are before the qualifiers of a lambda, we need to remember that the variables are still in the parent's context (rather than in the call operator's).

Reviewed By: aaron.ballman, #clang-language-wg, ChuanqiXu

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

show more ...

Revert "[clang] Implement Change scope of lambda trailing-return-type"

This reverts commit c729d5be781a8e80137c11ab28aa14d9ace148db.

This change breaks thread safety annotations on lambdas.

[clang] Implement Change scope of lambda trailing-return-type

Implement P2036R3.

Captured variables by copy (explicitely or not), are deduced
correctly at the point we know whether the lambda is mu

[clang] Implement Change scope of lambda trailing-return-type

Implement P2036R3.

Captured variables by copy (explicitely or not), are deduced
correctly at the point we know whether the lambda is mutable,
and ill-formed before that.

Up until now, the entire lambda declaration up to the start
of the body would be parsed in the parent scope, such that
captures would not be available to look up.

The scoping is changed to have an outer lambda scope,
followed by the lambda prototype and body.

The lambda scope is necessary because there may be a template scope
between the start of the lambda (to which we want to attach
the captured variable) and the prototype scope.

We also need to introduce a declaration context to attach the captured
variable to (and several parts of clang assume captures are handled from
the call operator context), before we know the type of the call operator.

The order of operations is as follow:

* Parse the init capture in the lambda's parent scope
* Introduce a lambda scope
* Create the lambda class and call operator
* Add the init captures to the call operator context and the lambda scope.
But the variables are not capured yet (because we don't know their type).
Instead, explicit captures are stored in a temporary map that
conserves the order of capture (for the purpose of having a stable order in the ast dumps).

* A flag is set on LambdaScopeInfo to indicate that we have not yet injected the captures.

* The parameters are parsed (in the parent context, as lambda mangling recurses in the parent context,
we couldn't mangle a lambda that is attached to the context of a lambda whose type is not yet known).

* The lambda qualifiers are parsed, at this point,
we can switch (for the second time) inside the lambda context,
unset the flag indicating that we have not parsed the lambda qualifiers,
record the lambda is mutable and capture the explicit variables.

* We can parse the rest of the lambda type, transform the lambda and call operator's types and also
transform the call operator to a template function decl where necessary.

At this point, both captures and parameters can be injected in the body's scope.
When trying to capture an implicit variable, if we are before the qualifiers of a lambda,
we need to remember that the variables are still in the parent's context (rather than in the call operator's).

This is a recommit of adff142dc2 after a fix in d8d793f29b4

Reviewed By: aaron.ballman, #clang-language-wg, ChuanqiXu

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

show more ...

Revert "[clang] Implement Change scope of lambda trailing-return-type"

This reverts commit adff142dc253d65b6560e420bba6b858d88d4a98.
This broke clang bootstrap: it made existing C++ code in LLVM inv

Revert "[clang] Implement Change scope of lambda trailing-return-type"

This reverts commit adff142dc253d65b6560e420bba6b858d88d4a98.
This broke clang bootstrap: it made existing C++ code in LLVM invalid:

llvm/include/llvm/CodeGen/LiveInterval.h:630:53: error: captured variable 'Idx' cannot appear here
[=](std::remove_reference_t<decltype(*Idx)> V,
^

show more ...

[clang] Implement Change scope of lambda trailing-return-type

Implement P2036R3.

Captured variables by copy (explicitely or not), are deduced
correctly at the point we know whether the lambda is mu

[clang] Implement Change scope of lambda trailing-return-type

Implement P2036R3.

Captured variables by copy (explicitely or not), are deduced
correctly at the point we know whether the lambda is mutable,
and ill-formed before that.

Up until now, the entire lambda declaration up to the start of the body would be parsed in the parent scope, such that capture would not be available to look up.

The scoping is changed to have an outer lambda scope, followed by the lambda prototype and body.

The lambda scope is necessary because there may be a template scope between the start of the lambda (to which we want to attach the captured variable) and the prototype scope.

We also need to introduce a declaration context to attach the captured variable to (and several parts of clang assume captures are handled from the call operator context), before we know the type of the call operator.

The order of operations is as follow:

* Parse the init capture in the lambda's parent scope

* Introduce a lambda scope

* Create the lambda class and call operator

* Add the init captures to the call operator context and the lambda scope. But the variables are not capured yet (because we don't know their type).
Instead, explicit captures are stored in a temporary map that conserves the order of capture (for the purpose of having a stable order in the ast dumps).

* A flag is set on LambdaScopeInfo to indicate that we have not yet injected the captures.

* The parameters are parsed (in the parent context, as lambda mangling recurses in the parent context, we couldn't mangle a lambda that is attached to the context of a lambda whose type is not yet known).

* The lambda qualifiers are parsed, at this point We can switch (for the second time) inside the lambda context, unset the flag indicating that we have not parsed the lambda qualifiers,
record the lambda is mutable and capture the explicit variables.

* We can parse the rest of the lambda type, transform the lambda and call operator's types and also transform the call operator to a template function decl where necessary.

At this point, both captures and parameters can be injected in the body's scope. When trying to capture an implicit variable, if we are before the qualifiers of a lambda, we need to remember that the variables are still in the parent's context (rather than in the call operator's).

Reviewed By: aaron.ballman, #clang-language-wg, ChuanqiXu

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

show more ...

[C++17] Reject shadowing of capture by parameter in lambda

Summary:
This change rejects the shadowing of a capture by a parameter in lambdas in C++17.

```
int main() {
int a;
auto f = [a](int a

[C++17] Reject shadowing of capture by parameter in lambda

Summary:
This change rejects the shadowing of a capture by a parameter in lambdas in C++17.

```
int main() {
int a;
auto f = [a](int a) { return a; };
}
```

results in:

```
main.cpp:3:20: error: a lambda parameter cannot shadow an explicitly captured entity
auto f = [a](int a) { return a; };
^
main.cpp:3:13: note: variable a is explicitly captured here
auto f = [a](int a) { return a; };
^
```

Reviewers: rsmith

Reviewed By: rsmith

Subscribers: lebedev.ri, erik.pilkington, cfe-commits

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

llvm-svn: 345308

show more ...

[Sema] Avoid -Wshadow warning when a "redefinition of " error is presented

This commit ensures that clang avoids the redundant -Wshadow warning for
variables that already get a "redefinition of " er

[Sema] Avoid -Wshadow warning when a "redefinition of " error is presented

This commit ensures that clang avoids the redundant -Wshadow warning for
variables that already get a "redefinition of " error.

rdar://29067894

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

llvm-svn: 291564

show more ...

[Sema] Avoid -Wshadow warnings for shadowed variables that
aren't captured by lambdas with a default capture specifier

This commit is a follow-up to r286354. It avoids the -Wshadow warning for
varia

[Sema] Avoid -Wshadow warnings for shadowed variables that
aren't captured by lambdas with a default capture specifier

This commit is a follow-up to r286354. It avoids the -Wshadow warning for
variables which shadow variables that aren't captured by lambdas with a default
capture specifier. It provides an additional note that points to location of
the capture.

The old behaviour is preserved with -Wshadow-all or -Wshadow-uncaptured-local.

rdar://14984176

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

llvm-svn: 286465

show more ...

[Sema] Avoid -Wshadow warnings for shadowed variables that aren't captured
by lambdas with an explicit capture list

This commit avoids the -Wshadow warning for variables which shadow variables
that

[Sema] Avoid -Wshadow warnings for shadowed variables that aren't captured
by lambdas with an explicit capture list

This commit avoids the -Wshadow warning for variables which shadow variables
that aren't captured by lambdas with an explicit capture list. It provides an
additional note that points to location of the explicit capture.

The old behaviour is preserved with -Wshadow-all or -Wshadow-uncaptured-local.

rdar://17135966

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

llvm-svn: 286354

show more ...