[Sema] Add some basic lambda capture fix-its

Adds fix-its when users forget to explicitly capture variables or this in lambdas

Addresses https://github.com/clangd/clangd/issues/697

Reviewed By: kb

[Sema] Add some basic lambda capture fix-its

Adds fix-its when users forget to explicitly capture variables or this in lambdas

Addresses https://github.com/clangd/clangd/issues/697

Reviewed By: kbobyrev

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

show more ...

[clang][PATCH][NFC] Correct test case related to review D95482

[clang][PATCH] Fix bug 48848 assertion related to recoverFromMSUnqualifiedLookup

Reviewed By: rnk

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

[clang] Improve diagnostics for auto-return-type function if the return expr had an error.

Given the following case:

```
auto k() {
return undef();
return 1;
}
```

Prior to the patch, clang em

[clang] Improve diagnostics for auto-return-type function if the return expr had an error.

Given the following case:

```
auto k() {
return undef();
return 1;
}
```

Prior to the patch, clang emits an `cannot initialize return object of type
'auto' with an rvalue of type 'int'` diagnostic on the second return
(because the return type of the function cannot be deduced from the first contain-errors return).

This patch suppresses this error.

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

show more ...

[clang][NFC] Tests showing the problems with some uses of NamedDecl::getDeclName in diagnostics, SemaExpr.cpp part

DR458: Search template parameter scopes in the right order.

C++ unqualified name lookup searches template parameter scopes
immediately after finishing searching the entity the parameters belong
to.

DR458: Search template parameter scopes in the right order.

C++ unqualified name lookup searches template parameter scopes
immediately after finishing searching the entity the parameters belong
to. (Eg, for a class template, you search the template parameter scope
after looking in that class template and its base classes and before
looking in the scope containing the class template.) This is complicated
by the fact that scope lookup within a template parameter scope looks in
a different sequence of places prior to reaching the end of the
declarator-id in the template declaration.

We used to approximate the proper lookup rule with a hack in the scope /
decl context walk inside name lookup. Now we instead compute the lookup
parent for each template parameter scope.

In order to get this right, we now make sure to enter a distinct Scope
for each template parameter scope, and make sure to re-enter the
enclosing class scopes properly when handling delay-parsed regions
within a class.

show more ...

Revert "DR458: Search template parameter scopes in the right order."

We weren't re-entering template scopes in the right order, causing this
to break self-host with -fdelayed-template-parsing.

This

Revert "DR458: Search template parameter scopes in the right order."

We weren't re-entering template scopes in the right order, causing this
to break self-host with -fdelayed-template-parsing.

This reverts commit 237c2a23b6d4fa953f5ae910dccf492db61bb959.

show more ...

DR458: Search template parameter scopes in the right order.

C++ unqualified name lookup searches template parameter scopes
immediately after finishing searching the entity the parameters belong
to.

DR458: Search template parameter scopes in the right order.

C++ unqualified name lookup searches template parameter scopes
immediately after finishing searching the entity the parameters belong
to. (Eg, for a class template, you search the template parameter scope
after looking in that class template and its base classes and before
looking in the scope containing the class template.) This is complicated
by the fact that scope lookup within a template parameter scope looks in
a different sequence of places prior to reaching the end of the
declarator-id in the template declaration.

We used to approximate the proper lookup rule with a hack in the scope /
decl context walk inside name lookup. Now we instead compute the lookup
parent for each template parameter scope. This gets the right answer and
as a bonus is substantially simpler and more uniform.

In order to get this right, we now make sure to enter a distinct Scope
for each template parameter scope. (The fact that we didn't before was
already a bug, but not really observable most of the time, since
template parameters can't shadow each other.)

show more ...

Fix crash-on-invalid-code in lambda constant evaluation.

If the lambda used 'this' without without capturing it, an error was
emitted, but the constant evaluator would still attempt to lookup the
ca

Fix crash-on-invalid-code in lambda constant evaluation.

If the lambda used 'this' without without capturing it, an error was
emitted, but the constant evaluator would still attempt to lookup the
capture, and failing to find it, dereference a null pointer.

This only happens in C++17 (as that's when lambdas were made
potentially-constexpr). Therefore, I also updated the
lambda-expressions.cpp test to run in both C++14 and C++17 modes.

show more ...

PR43242: Fix crash when typo-correcting to an operator() that should not
have been visible.

llvm-svn: 371468

Defer building 'this' captures until we have left the capturing region
and returned to the context in which 'this' should be captured.

This means we now always mark 'this' referenced from the contex

Defer building 'this' captures until we have left the capturing region
and returned to the context in which 'this' should be captured.

This means we now always mark 'this' referenced from the context in
which it's actually referenced, rather than potentially from some
context nested within that.

llvm-svn: 362182

show more ...

If capturing a variable fails, add a capture anyway (and mark it
invalid) so that we can avoid repeated diagnostics for the same capture.

llvm-svn: 361891

Diagnose non-dependent qualified friend function template declarations
that don't match any existing declaration. Don't get confused and treat
such declarations as template *specializations*.

llvm-s

Diagnose non-dependent qualified friend function template declarations
that don't match any existing declaration. Don't get confused and treat
such declarations as template *specializations*.

llvm-svn: 359746

show more ...

Fix crash on invalid.

Don't call a method when the pointer is null.

llvm-svn: 324308

Fix and simplify handling of return type for (generic) lambda conversion function to function pointer.

Previously, we would:
* compute the type of the conversion function and static invoker as a

Fix and simplify handling of return type for (generic) lambda conversion function to function pointer.

Previously, we would:
* compute the type of the conversion function and static invoker as a
side-effect of template argument deduction for a conversion
* re-compute the type as part of deduced return type deduction when building
the conversion function itself

Neither of these turns out to be quite correct. There are other ways to reach a
declaration of the conversion function than in a conversion (such as an
explicit call or friend declaration), and performing auto deduction causes the
function type to be rebuilt in the context of the lambda closure type (which is
different from the context in which it originally appeared, resulting in
spurious substitution failures for constructs that are valid in one context but
not the other, such as the use of an enclosing class's "this" pointer).

This patch switches us to use a different strategy: as before, we use the
declared type of the operator() to form the type of the conversion function and
invoker, but we now populate that type as part of return type deduction for the
conversion function. And the invoker is now treated as simply being an
implementation detail of building the conversion function, and isn't given
special treatment by template argument deduction for the conversion function
any more.

llvm-svn: 321683

show more ...

Fix PR25627: constant expressions being odr-used in template arguments.

This patch ensures that clang processes the expression-nodes that are generated when disambiguating between types and expressi

Fix PR25627: constant expressions being odr-used in template arguments.

This patch ensures that clang processes the expression-nodes that are generated when disambiguating between types and expressions within template arguments as constant-expressions by installing the ConstantEvaluated ExpressionEvaluationContext just before attempting the disambiguation - and then making sure that Context carries through into ParseConstantExpression (by refactoring it out into a function that does not create its own EvaluationContext: ParseConstantExpressionInExprEvalContext)

Note, prior to this patch, trunk would correctly disambiguate and identify the expression as an expression - and while it would annotate the token with the expression - it would fail to complete the odr-use processing (specifically, failing to trigger Sema::UpdateMarkingForLValueToRValue as is done for all Constant Expressions, which would remove it from being considered odr-used). By installing the ConstantExpression Evaluation Context prior to disambiguation, and making sure it carries though, we ensure correct processing of the expression-node.

For e.g:
template<int> struct X { };
void f() {
const int N = 10;
X<N> x; // should be OK.
[] { return X<N>{}; }; // Should be OK - no capture - but clang errors!
}

See a related bug: https://bugs.llvm.org//show_bug.cgi?id=25627

In summary (and reiteration), the fix is as follows:

- Remove the EnteredConstantEvaluatedContext action from ParseTemplateArgumentList (relying on ParseTemplateArgument getting it right)
- Add the EnteredConstantEvaluatedContext action just prior to undergoing the disambiguating parse, and if the parse succeeds for an expression, carry the context though into a refactored version of ParseConstantExpression that does not create its own ExpressionEvaluationContext.

See https://reviews.llvm.org/D31588 for additional context regarding some of the more fragile and complicated approaches attempted, and Richard's feedback that eventually shaped the simpler and more robust rendition that is being committed.

Thanks Richard!

llvm-svn: 303492

show more ...

[Parser] Correct typo after lambda capture initializer is parsed.

This patch fixes an assertion that is triggered when RecordLayoutBuilder
tries to compute the size of a field (for capture "name" in

[Parser] Correct typo after lambda capture initializer is parsed.

This patch fixes an assertion that is triggered when RecordLayoutBuilder
tries to compute the size of a field (for capture "name" in the test
case) whose type hasn't been deduced. The patch fixes the bug by
correcting the typo of the capture initializer after the initializer is
parsed and before setting the expression for the annotation token.

Fixes PR30566.

rdar://problem/23380132

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

llvm-svn: 290156

show more ...

PR23281: Fix implementation of DR1891 to implement the intent: that is, a
lambda-expression does not have a move-assignment operator.

llvm-svn: 287057

[Sema] Teach getCurrentThisType to reconize lambda in in-class initializer

Fixes PR27994, a crash on valid.

Differential revision: https://reviews.llvm.org/D21145

llvm-svn: 276900

Add null check to diagnostic path for lambda captures.

Previously, the failed capture of a variable in nested lambdas may crash when
the lambda pointer is null. Only give the note if a location can

Add null check to diagnostic path for lambda captures.

Previously, the failed capture of a variable in nested lambdas may crash when
the lambda pointer is null. Only give the note if a location can be retreived
from the lambda pointer.

llvm-svn: 262765

show more ...

[SemaCXX] Fix crash-on-invalid while trying to deduce return type of a lambda.

rdar://22032373

llvm-svn: 259287

Classes inside lambdas are local not nested.

If a lambda used as default argument in a method declaration contained
a local class, that class was incorrectly recognized as nested class.
In this case

Classes inside lambdas are local not nested.

If a lambda used as default argument in a method declaration contained
a local class, that class was incorrectly recognized as nested class.
In this case compiler tried to postpone parsing of this class until
the enclosing class is finished, which caused crashes in some cases.

This change fixes PR13987.

Differential Revision: http://reviews.llvm.org/D11006

llvm-svn: 242132

show more ...

PR21857: weaken an incorrect assertion.

llvm-svn: 228785

DR1048: drop top-level cv-qualifiers when deducing the return type of a
lambda-expression in C++11, to match the C++14 rules.

llvm-svn: 224620

Handle errors in lambda prototype instantiation correctly

Previously we would attempt to build a TypeSourceInfo for a null type,
and then we would forget to pop the function scope before returning a

Handle errors in lambda prototype instantiation correctly

Previously we would attempt to build a TypeSourceInfo for a null type,
and then we would forget to pop the function scope before returning an
error.

Reviewers: rsmith

Differential Revision: http://reviews.llvm.org/D6665

llvm-svn: 224271

show more ...