[Clang] Delegate part of SetupConstraintScope's job to LambdaScopeForCallOperatorInstantiationRAII (#123687)

Now that the RAII object has a dedicate logic for handling nested
lambdas, where the inne

[Clang] Delegate part of SetupConstraintScope's job to LambdaScopeForCallOperatorInstantiationRAII (#123687)

Now that the RAII object has a dedicate logic for handling nested
lambdas, where the inner lambda could reference any
captures/variables/parameters from the outer lambda, we can shift the
responsibility for managing lambdas away from SetupConstraintScope().

I think this also makes the structure clearer.

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

show more ...

[Clang][Sema] Bump the instantiated index when skipping past non-init-captures (#110887)

Otherwise, we would probably have an unmatched instantiated declaration
for init-captures when they come afte

[Clang][Sema] Bump the instantiated index when skipping past non-init-captures (#110887)

Otherwise, we would probably have an unmatched instantiated declaration
for init-captures when they come after a non-init capture.

No release note because the bug only affects the trunk so far.

Fixes #110721

show more ...

[Clang] Fix Handling of Init Capture with Parameter Packs in LambdaScopeForCallOperatorInstantiationRAII (#100766)

This PR addresses issues related to the handling of `init capture` with
parameter

[Clang] Fix Handling of Init Capture with Parameter Packs in LambdaScopeForCallOperatorInstantiationRAII (#100766)

This PR addresses issues related to the handling of `init capture` with
parameter packs in Clang's
`LambdaScopeForCallOperatorInstantiationRAII`.

Previously, `addInstantiatedCapturesToScope` would add `init capture`
containing packs to the scope using the type of the `init capture` to
determine the expanded pack size. However, this approach resulted in a
pack size of 0 because `getType()->containsUnexpandedParameterPack()`
returns `false`. After extensive testing, it appears that the correct
pack size can only be inferred from `getInit`.

But `getInit` may reference parameters and `init capture` from an outer
lambda, as shown in the following example:

```cpp
auto L = [](auto... z) {
return [... w = z](auto... y) {
// ...
};
};
```

To address this, `addInstantiatedCapturesToScope` in
`LambdaScopeForCallOperatorInstantiationRAII` should be called last.
Additionally, `addInstantiatedCapturesToScope` has been modified to only
add `init capture` to the scope. The previous implementation incorrectly
called `MakeInstantiatedLocalArgPack` for other non-init captures
containing packs, resulting in a pack size of 0.

### Impact

This patch affects scenarios where
`LambdaScopeForCallOperatorInstantiationRAII` is passed with
`ShouldAddDeclsFromParentScope = false`, preventing the correct addition
of the current lambda's `init capture` to the scope. There are two main
scenarios for `ShouldAddDeclsFromParentScope = false`:

1. **Constraints**: Sometimes constraints are instantiated in place
rather than delayed. In this case,
`LambdaScopeForCallOperatorInstantiationRAII` does not need to add `init
capture` to the scope.
2. **`noexcept` Expressions**: The expressions inside `noexcept` have
already been transformed, and the packs referenced within have been
expanded. Only `RebuildLambdaInfo` needs to add the expanded captures to
the scope, without requiring `addInstantiatedCapturesToScope` from
`LambdaScopeForCallOperatorInstantiationRAII`.

### Considerations

An alternative approach could involve adding a data structure within the
lambda to record the expanded size of the `init capture` pack. However,
this would increase the lambda's size and require extensive
modifications.

This PR is a prerequisite for implmenting
https://github.com/llvm/llvm-project/issues/61426

show more ...

[Clang] Fix the order of addInstantiatedParameters in LambdaScopeForCallOperatorInstantiationRAII (#97215)

Currently, `addInstantiatedParameters` is called from the innermost
lambda outward. However

[Clang] Fix the order of addInstantiatedParameters in LambdaScopeForCallOperatorInstantiationRAII (#97215)

Currently, `addInstantiatedParameters` is called from the innermost
lambda outward. However, when the function parameters of an inner lambda
depend on the function parameters of an outer lambda, it can lead to a
crash due to the inability to find a mapping for the instantiated decl.

This PR corrects this behavior by calling `addInstantiatedParameters`
from the outside in.

repro code: https://godbolt.org/z/KbsxWesW6

```cpp
namespace dependent_param_concept {
template <typename... Ts> void sink(Ts...) {}
void dependent_param() {
auto L = [](auto... x) {
return [](decltype(x)... y) { // `y` depends on `x`
return [](int z)
requires requires { sink(y..., z); }
{};
};
};
L(0, 1)(1, 2)(1);
}
} // namespace dependent_param_concept
```

This PR is a prerequisite for implmenting #61426

show more ...

[Clang][Sema] Push an evaluation context for type constraints (#93945)

This helps getTemplateInstantiationArgs() to properly recover template
arguments of an enclosing concept Decl.

Fixes https:

[Clang][Sema] Push an evaluation context for type constraints (#93945)

This helps getTemplateInstantiationArgs() to properly recover template
arguments of an enclosing concept Decl.

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

show more ...

[clang][Sema] Skip the RequiresExprBodyDecls for lambda dependencies (#83997)

The dependency of a lambda inside of a `RequiresExprBodyDecl` was
previously affected by its parent, e.g.,
`ClassTempl

[clang][Sema] Skip the RequiresExprBodyDecls for lambda dependencies (#83997)

The dependency of a lambda inside of a `RequiresExprBodyDecl` was
previously affected by its parent, e.g.,
`ClassTemplateSpecializationDecl`. This made the lambda always dependent
regardless of the template arguments we had, which caused some crashes
on the constraint evaluation later.

This fixes https://github.com/llvm/llvm-project/issues/56556, fixes
https://github.com/llvm/llvm-project/issues/82849 and a case
demonstrated by
https://github.com/llvm/llvm-project/issues/49570#issuecomment-1664966972.

show more ...

[Concepts] Traverse the instantiation chain for parameter injection inside a constraint scope (#79568)

We preserve the trailing requires-expression during the lambda
expression transformation. In o

[Concepts] Traverse the instantiation chain for parameter injection inside a constraint scope (#79568)

We preserve the trailing requires-expression during the lambda
expression transformation. In order to get those referenced parameters
inside a requires-expression properly resolved to the instantiated
decls, we intended to inject these 'original' `ParmVarDecls` to the
current instantiaion scope, at `Sema::SetupConstraintScope`.

The previous approach seems to overlook nested instantiation chains,
leading to the crash within a nested lambda followed by a requires
clause.

This fixes https://github.com/llvm/llvm-project/issues/73418.

show more ...

[Clang] Fix the instantiation of return type requirements in lambda bodies (#76967)

Currently, due to the incomplete implementation of p0588r1, the
instantiation of lambda expressions leads to the

[Clang] Fix the instantiation of return type requirements in lambda bodies (#76967)

Currently, due to the incomplete implementation of p0588r1, the
instantiation of lambda expressions leads to the instantiation of the
body. And `EvaluateConstraints` is false during the instantiation of the
body, which causes crashes during the instantiation of the return type
requirement:

```cpp
template<typename T> concept doesnt_matter = true;

template<class T>
concept test =
[]{
return requires(T t) {
{ t } -> doesnt_matter; // crash
};
}();

static_assert(test<int>);
```

Although a complete implementation of p0588r1 can solve these crashes,
it will take some time. Therefore, this pull request aims to fix these
crashes first.

Fixes https://github.com/llvm/llvm-project/issues/63808
Fixes https://github.com/llvm/llvm-project/issues/64607
Fixes https://github.com/llvm/llvm-project/issues/64086

show more ...

GH60642: Fix ICE when checking a lambda defined in a concept definition

As reported in GH60642, we asserted when there was a lambda defined in a
template arguments inside of a concept, which caused

GH60642: Fix ICE when checking a lambda defined in a concept definition

As reported in GH60642, we asserted when there was a lambda defined in a
template arguments inside of a concept, which caused us to not properly
set up the list of instantiation args. This patch ensures that the
'lambda context decl' correctly falls-through the template argument
instantiation, so that it is available when instantiating the lambda,
and thus, when setting up the lambda instantiation args list.

show more ...

"Reapply "GH58368: Correct concept checking in a lambda defined in concept""

This reverts commit cecc9a92cfca71c1b6c2a35c5e302ab649496d11.

The problem ended up being how we were handling the lambda

"Reapply "GH58368: Correct concept checking in a lambda defined in concept""

This reverts commit cecc9a92cfca71c1b6c2a35c5e302ab649496d11.

The problem ended up being how we were handling the lambda-context in
code generation: we were assuming any decl context here would be a
named-decl, but that isn't the case. Instead, we just replace it with
the concept's owning context.

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

show more ...

Revert "Reapply "GH58368: Correct concept checking in a lambda defined in concept"""

This reverts commit b876f6e2f28779211a829d7d4e841fe68885ae20.

Still getting build failures on PPC AIX that aren'

Revert "Reapply "GH58368: Correct concept checking in a lambda defined in concept"""

This reverts commit b876f6e2f28779211a829d7d4e841fe68885ae20.

Still getting build failures on PPC AIX that aren't obvious what is causing
them, so reverting while I try to figure this out.

show more ...

Reapply "GH58368: Correct concept checking in a lambda defined in concept""

This reverts commit 52930162870fee52d0d9c07c5d66e5dce32b08e8.

Now with updating the ASTBitcodes to show that this AST is

Reapply "GH58368: Correct concept checking in a lambda defined in concept""

This reverts commit 52930162870fee52d0d9c07c5d66e5dce32b08e8.

Now with updating the ASTBitcodes to show that this AST is incompatible
from the last.

show more ...

Revert "GH58368: Correct concept checking in a lambda defined in concept"

This reverts commit b7c922607c5ba93db8b893d4ba461052af8317b5.

This seems to cause some problems with some modules related t

Revert "GH58368: Correct concept checking in a lambda defined in concept"

This reverts commit b7c922607c5ba93db8b893d4ba461052af8317b5.

This seems to cause some problems with some modules related things,
which makes me think I should have updated the version-major in
ast-bit-codes? Going to revert to confirm this was a problem, then
change that and re-try a commit.

show more ...

GH58368: Correct concept checking in a lambda defined in concept

As that bug reports, the problem here is that the lambda's
'context-decl' was not set to the concept, and the lambda picked up
templa

GH58368: Correct concept checking in a lambda defined in concept

As that bug reports, the problem here is that the lambda's
'context-decl' was not set to the concept, and the lambda picked up
template arguments from the concept. SO, we failed to get the correct
template arguments in SemaTemplateInstantiate.

However, a Concept Specialization is NOT a decl, its an expression, so
we weren't able to put the concept in the decl tree like we needed.
This patch introduces a ConceptSpecializationDecl, which is the smallest
type possible to use for this purpose, containing only the template
arguments.

The net memory impliciation of this is turning a
trailing-objects into a pointer to a type with trailing-objects, so it
should be minor.

As future work, we may consider giving this type more responsibility, or
figuring out how to better merge duplicates, but as this is just a
template-argument collection at the moment, there isn't much value to
it.

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

show more ...

[Concepts] Fix Concepts on generic lambda in a VarTemplateSpecDecl

As fallout of the Deferred Concept Instantiation patch (babdef27c5), we
got a number of reports of a regression, where we asserted

[Concepts] Fix Concepts on generic lambda in a VarTemplateSpecDecl

As fallout of the Deferred Concept Instantiation patch (babdef27c5), we
got a number of reports of a regression, where we asserted when
instantiating a constraint on a generic lambda inside of a variable
template. See: https://github.com/llvm/llvm-project/issues/57958

The problem was that getTemplateInstantiationArgs function only walked
up declaration contexts, and missed that this is not necessarily the
case with a lambda (which can ALSO be in a separate context).

This patch refactors the getTemplateInstantiationArgs function in a way
that is hopefully more readable, and fixes the problem with the concepts
on a generic lambda.

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

show more ...

Fix regression from Deferred Concepts with lambda in var init

As reported in GH #57945, this would crash because the decl context for
the lambda was being loaded via 'getNonClosureContext', which on

Fix regression from Deferred Concepts with lambda in var init

As reported in GH #57945, this would crash because the decl context for
the lambda was being loaded via 'getNonClosureContext', which only gets
CODE contexts, so a global lambda was getting 'nullptr' here instead.
This patch does some work to make sure we get a valid/valuable
declcontext here instead.

show more ...