[Clang] Correctly determine constexprness of dependent lambdas. (#124468)

We skipped checking if a lambda is constexpr if the parent context was
dependent, even if the lambda itself wasn't (and ther

[Clang] Correctly determine constexprness of dependent lambdas. (#124468)

We skipped checking if a lambda is constexpr if the parent context was
dependent, even if the lambda itself wasn't (and there is no other
opportunity to establish constexprness)


Fixes #114234
Fixes #97958

show more ...

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

[AArch64][SME] Add diagnostics for SME attributes on lambda functions (#121777)

CheckFunctionDeclaration emits diagnostics if any SME attributes are used
by a function definition without the requir

[AArch64][SME] Add diagnostics for SME attributes on lambda functions (#121777)

CheckFunctionDeclaration emits diagnostics if any SME attributes are used
by a function definition without the required +sme or +sme2 target features.
This patch moves these diagnostics to a new function in SemaARM and
also adds a call to this from ActOnStartOfLambdaDefinition.

show more ...

[SYCL] Basic diagnostics for the sycl_kernel_entry_point attribute. (#120327)

The `sycl_kernel_entry_point` attribute is used to declare a function that
defines a pattern for an offload kernel entr

[SYCL] Basic diagnostics for the sycl_kernel_entry_point attribute. (#120327)

The `sycl_kernel_entry_point` attribute is used to declare a function that
defines a pattern for an offload kernel entry point. The attribute requires
a single type argument that specifies a class type that meets the requirements
for a SYCL kernel name as described in section 5.2, "Naming of kernels", of
the SYCL 2020 specification. A unique kernel name type is required for each
function declared with the attribute. The attribute may not first appear on a
declaration that follows a definition of the function. The function is
required to have a non-deduced `void` return type. The function must not be
a non-static member function, be deleted or defaulted, be declared with the
`constexpr` or `consteval` specifiers, be declared with the `[[noreturn]]`
attribute, be a coroutine, or accept variadic arguments.

Diagnostics are not yet provided for the following:
- Use of a type as a kernel name that does not satisfy the forward
declarability requirements specified in section 5.2, "Naming of kernels",
of the SYCL 2020 specification.
- Use of a type as a parameter of the attributed function that does not
satisfy the kernel parameter requirements specified in section 4.12.4,
"Rules for parameter passing to kernels", of the SYCL 2020 specification
(each such function parameter constitutes a kernel parameter).
- Use of language features that are not permitted in device functions as
specified in section 5.4, "Language restrictions for device functions",
of the SYCL 2020 specification.

There are several issues noted by various FIXME comments.
- The diagnostic generated for kernel name conflicts needs additional work
to better detail the relevant source locations; such as the location of
each declaration as well as the original source of each kernel name.
- A number of the tests illustrate spurious errors being produced due to
attributes that appertain to function templates being instantiated too
early (during overload resolution as opposed to after an overload is
selected).

Included changes allow the `SYCLKernelEntryPointAttr` attribute to be
marked as invalid if a `sycl_kernel_entry_point` attribute is used incorrectly.
This is intended to prevent trying to emit an offload kernel entry point
without having to mark the associated function as invalid since doing so
would affect overload resolution; which this attribute should not do.
Unfortunately, Clang eagerly instantiates attributes that appertain to
functions with the result that errors might be issued for function
declarations that are never selected by overload resolution. Tests have
been added to demonstrate this. Further work will be needed to address
these issues (for this and other attributes).

show more ...

[Clang] SemaFunctionEffects: Fix bug where lambdas produced by template expansion weren't verified. (#116505)

---------

Co-authored-by: Doug Wyatt <dwyatt@apple.com>

[clang] Use {} instead of std::nullopt to initialize empty ArrayRef (#109399)

Follow up to #109133.

[Clang] [Sema] Don't crash on unexpanded pack in invalid block literal (#110762)

Consider #109148:
```c++
template <typename ...Ts>
void f() {
[] {
(^Ts);
};
}
```

When we

[Clang] [Sema] Don't crash on unexpanded pack in invalid block literal (#110762)

Consider #109148:
```c++
template <typename ...Ts>
void f() {
[] {
(^Ts);
};
}
```

When we encounter `^Ts`, we try to parse a block and subsequently call
`DiagnoseUnexpandedParameterPack()` (in `ActOnBlockArguments()`), which
sees `Ts` and sets `ContainsUnexpandedParameterPack` to `true` in the
`LambdaScopeInfo` of the enclosing lambda. However, the entire block is
subsequently discarded entirely because it isn’t even syntactically
well-formed. As a result, `ContainsUnexpandedParameterPack` is `true`
despite the lambda’s body no longer containing any unexpanded packs,
which causes an assertion the next time
`DiagnoseUnexpandedParameterPack()` is called.

This pr moves handling of unexpanded parameter packs into
`CapturingScopeInfo` instead so that the same logic is used for both
blocks and lambdas. This fixes this issue since the
`ContainsUnexpandedParameterPack` flag is now part of the block (and
before that, its `CapturingScopeInfo`) and no longer affects the
surrounding lambda directly when the block is parsed. Moreover, this
change makes blocks actually usable with pack expansion.

This fixes #109148.

show more ...

[Sema] Avoid repeated hash lookups (NFC) (#111090)

[Clang] nonblocking/nonallocating attributes: 2nd pass caller/callee analysis (#99656)

- In Sema, when encountering Decls with function effects needing
verification, add them to a vector, DeclsWith

[Clang] nonblocking/nonallocating attributes: 2nd pass caller/callee analysis (#99656)

- In Sema, when encountering Decls with function effects needing
verification, add them to a vector, DeclsWithEffectsToVerify.
- Update AST serialization to include DeclsWithEffectsToVerify.
- In AnalysisBasedWarnings, use DeclsWithEffectsToVerify as a work
queue, verifying functions with declared effects, and inferring (when
permitted and necessary) whether their callees have effects.

---------

Co-authored-by: Doug Wyatt <dwyatt@apple.com>
Co-authored-by: Sirraide <aeternalmail@gmail.com>
Co-authored-by: Erich Keane <ekeane@nvidia.com>

show more ...

[Clang] Fix handling of placeholder variables name in init captures (#107055)

We were incorrectly not deduplicating results when looking up `_` which,
for a lambda init capture, would result in an

[Clang] Fix handling of placeholder variables name in init captures (#107055)

We were incorrectly not deduplicating results when looking up `_` which,
for a lambda init capture, would result in an ambiguous lookup.

The same bug caused some diagnostic notes to be emitted twice.

Fixes #107024

show more ...

[clang][NFC] Clean up `Sema` headers

When various `Sema*.h` and `Sema*.cpp` files were created, cleanup of
`Sema.h` includes and forward declarations was left for the later.
Now's the time. This com

[clang][NFC] Clean up `Sema` headers

When various `Sema*.h` and `Sema*.cpp` files were created, cleanup of
`Sema.h` includes and forward declarations was left for the later.
Now's the time. This commit touches `Sema.h` and Sema components:
1. Unused includes are removed.
2. Unused forward declarations are removed.
3. Missing includes are added (those files are largely IWYU-clean now).
4. Includes were converted into forward declarations where possible.

As this commit focuses on headers, all changes to `.cpp` files were
minimal, and were aiming at keeping everything buildable.

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

[Sema] Preserve ContainsUnexpandedParameterPack in TransformLambdaExpr (#86265)

The lambda `ContainsUnexpandedParameterPack` flag is used for the
expressions' dependency computing and is therefore

[Sema] Preserve ContainsUnexpandedParameterPack in TransformLambdaExpr (#86265)

The lambda `ContainsUnexpandedParameterPack` flag is used for the
expressions' dependency computing and is therefore essential for pack
expansion. We previously lost the flag's preservation during the
lambda's transform, which caused some issues, e.g. a fold expression
couldn't properly expand inside a template.

This patch alleviates the issue by retaining the flag in more scenarios.
Note that we still have problems with constraints involving packs
regarding lambdas, and dealing with that would take more effort, and
we'd like to fix them in the future.

Fixes https://github.com/llvm/llvm-project/issues/56852
Fixes https://github.com/llvm/llvm-project/issues/85667
Mitigates https://github.com/llvm/llvm-project/issues/99877 because the
attributes were not handled in this patch.

---------

Co-authored-by: Ilya Biryukov <809452+ilya-biryukov@users.noreply.github.com>
Co-authored-by: cor3ntin <corentinjabot@gmail.com>

show more ...

[Clang] Correctly recognize unexpanded packs in lambda template params (#98496)

Fixes #48937
Fixes #49099

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

[Sema] Fix -Wunused-but-set-variable after #94865

[Clang] Improve error message for lambda captures that name a class member (#94865)

This introduces are more helpful error message when trying to
explicitly capture a class member in a lambda.

[Clang] Improve error message for lambda captures that name a class member (#94865)

This introduces are more helpful error message when trying to
explicitly capture a class member in a lambda.

Fixes #94764.

show more ...

[Sema] LambdaScopeForCallOperatorInstantiationRAII - fix typo in early out logic (#96888)

We should be checking for a failed dyn_cast on the ParentFD result - not the loop invariant FD root value.

[Sema] LambdaScopeForCallOperatorInstantiationRAII - fix typo in early out logic (#96888)

We should be checking for a failed dyn_cast on the ParentFD result - not the loop invariant FD root value.

Seems to have been introduced in #65193

Noticed by static analyser (I have no specific test case).

show more ...

[Clang][Sema] Tweak tryCaptureVariable for unevaluated lambdas (#93206)

This patch picks up #78598 with the hope that we can address such
crashes in `tryCaptureVariable()` for unevaluated lambdas.

[Clang][Sema] Tweak tryCaptureVariable for unevaluated lambdas (#93206)

This patch picks up #78598 with the hope that we can address such
crashes in `tryCaptureVariable()` for unevaluated lambdas.

In addition to `tryCaptureVariable()`, this also contains several other
fixes on e.g. lambda parsing/dependencies.

Fixes #63845
Fixes #67260
Fixes #69307
Fixes #88081
Fixes #89496
Fixes #90669
Fixes #91633

show more ...

[Clang] Perform derived-to-base conversion on explicit object parameter in lambda (#89828)

Consider this code:
```c++
template <typename... Ts>
struct Overloaded : Ts... { using Ts::operator()...

[Clang] Perform derived-to-base conversion on explicit object parameter in lambda (#89828)

Consider this code:
```c++
template <typename... Ts>
struct Overloaded : Ts... { using Ts::operator()...; };

template <typename... Ts>
Overloaded(Ts...) -> Overloaded<Ts...>;

void f() {
int x;
Overloaded o {
[&](this auto& self) {
return &x;
}
};
o();
}
```

To access `x` in the lambda, we need to perform derived-to-base
conversion on `self` (since the type of `self` is not the lambda type,
but rather `Overloaded<(lambda type)>`). We were previously missing this
step, causing us to attempt to load the entire lambda (as the base
class, it would end up being the ‘field’ with index `0` here), which
would then assert later on in codegen.

Moreover, this is only valid in the first place if there is a unique and
publicly accessible cast path from the derived class to the lambda’s
type, so this also adds a check in Sema to diagnose problematic
cases.

This fixes #87210 and fixes #89541.

show more ...

[clang] Introduce `SemaOpenMP` (#88642)

This patch moves OpenMP-related entities out of `Sema` to a newly
created `SemaOpenMP` class. This is a part of the effort to split `Sema`
up, and follows t

[clang] Introduce `SemaOpenMP` (#88642)

This patch moves OpenMP-related entities out of `Sema` to a newly
created `SemaOpenMP` class. This is a part of the effort to split `Sema`
up, and follows the recent example of CUDA, OpenACC, SYCL, HLSL.
Additional context can be found in
https://github.com/llvm/llvm-project/pull/82217,
https://github.com/llvm/llvm-project/pull/84184,
https://github.com/llvm/llvm-project/pull/87634.

show more ...

[clang] Introduce `SemaCUDA` (#88559)

This patch moves CUDA-related `Sema` function into new `SemaCUDA` class,
following the recent example of SYCL, OpenACC, and HLSL. This is a part
of the effort

[clang] Introduce `SemaCUDA` (#88559)

This patch moves CUDA-related `Sema` function into new `SemaCUDA` class,
following the recent example of SYCL, OpenACC, and HLSL. This is a part
of the effort to split Sema. Additional context can be found in
https://github.com/llvm/llvm-project/pull/82217,
https://github.com/llvm/llvm-project/pull/84184,
https://github.com/llvm/llvm-project/pull/87634.

show more ...

[Clang][Sema][NFC] Remove unused Scope* parameter from Sema::GetTypeForDeclarator and Sema::ActOnTypeName (#78325)

Split from #78274

[clang][NFC] Remove unused parameter

[Clang][Sema] Don't say "is declared here" for invalid template locations

If a template is defined via an external AST source, it won't have a
location. When we emit warnings about misusing such tem

[Clang][Sema] Don't say "is declared here" for invalid template locations

If a template is defined via an external AST source, it won't have a
location. When we emit warnings about misusing such templates we
shouldn't emit a "template is declared here" warning with no location,
as that's just confusing.

Reviewers: llvm-beanz, erichkeane, AaronBallman

Reviewed By: erichkeane, AaronBallman

Pull Request: https://github.com/llvm/llvm-project/pull/71264

show more ...