Fixes #118187
Fixes #156579

An instantiated `LambdaExpr` can currently be marked as
`LDK_NeverDependent` if it's nested within a generic lambda. If that
`LambdaExpr` in fact depends on template parameters introduced by the
enclosing generic lambda, then its dependence will be misreported as
"never dependent" and spurious diagnostics can result.

The fix here proposed is a bit ugly, but the condition that it's being
bolted onto already seems like a bit of a hack, so this seems no worse
for wear.

Note that #89702 surfaced this change because it caused the inner lambda
expression to (correctly) be considered in a constant-evaluated context.
The affected check for whether to mark the inner lambda as
`LDK_NeverDependent` therefore started to apply, whereas it didn't
before.

**Tested**: `check-clang` and `check-cxx`.

This reverts 4d10c1165442cbbbc0017b48fcdd7dae1ccf3678 and its two
dependent commits: e6b9805b574bb5c90263ec7fbcb94df76d2807a4 and
c243406a695ca056a07ef4064b0f9feee7685320, see discussion in
https://github.com/llvm/llvm-project/pull/165598#issuecomment-3563825509.

Previously, the presence of an explicit parameter list was detected by
querying `getNumTypeObjects()` from the `Declarator` block of the lambda
definition. This breaks for lambdas which do not have a parameter list
but _do_ have a trailing return type; that is, both of

```
[]() -> int { return 0; };
[] -> int { return 0; };
```

would return `true` when inspecting
`LambdaExpr::hasExplicitParameters()`.

Fix this by instead querying the `LParenLoc()` from the `Declarator`'s
`FunctionTypeInfo`. If `isValid() == true`, then an explicit parameter
list must be present, and if it is `false`, then it is not.

This commit also adds `hasExplicitParameters` as an attribute to a
`LambdaExpr`'s JSON AST dump. A new test (`ast-dump-lambda-json.cpp`) is
also added to validate the fix and presence of the new attribute in the
output. `ast-dump-expr-json.cpp` is also updated to validate the new
attribute.

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

Adds the remaining optional feature macros from the OpenCL C 3.0 spec
(section 6.2.1 table). Targets can now enable these via
OpenCLFeaturesMap returned by getSupportedOpenCLOpts().

Revert a84599f177a6 (header‑only feature macros).
Header‑only macros are difficult to disable on SPIR-V targets,
and the prior undef approach (a60b8f468119) does not scale.
After this PR, they can be disabled via `-cl-ext=-<feature>`.

https://github.com/KhronosGroup/OpenCL-Docs/issues/1328 also notes that
unconditional definition of the header‑only macros in opencl-c-base.h
should be removed.

Added diagnosis and fixit comment for possible accidental comparison
operator in an enum.

Closes: #168146

- Fixes https://github.com/llvm/llvm-project/issues/166512
- `ComplexExprEmitter::EmitCompoundAssignLValue` is calling
`EmitLoadOfScalar(LValue, SourceLocation)` to load the LHS value in the
case that it's non-complex, however this function requires that the
value is a simple LValue - issue occurred because the LValue in question
was a bitfield LValue. I changed it to use this function which seems to
handle all of the different cases (deferring to the original
`EmitLoadOfScalar` if it's a simple LValue)

The "malloc" attribute restricts the possible function signatures to the
ones returning a pointer, which is not the case for some non-standard
allocation function variants. For example, P0901R11 proposed ::operator
new overloads that return a return_size_t result - a struct that
contains a pointer to the allocated memory as well as the actual size of
the allocated memory. Another example is __size_returning_new.

Introduce a new "malloc_span" attribute that exhibits similar semantics,
but applies to functions returning records where one member is a pointer
(assumed to point to the allocated memory) and another is an integer
(assumed to be the size of the allocated memory). This is the case for
return_size_t as well as std::span, should it be returned from such an
annotated function.

An alternative approach would be to relax the restrictions of the
existing "malloc" attribute to be applied to both functions returning
pointers and functions returning span-like structs. However, it would
complicate the user-space code by requiring specific Clang version
checks. In contrast, the presence of a new attribute can be
straightforwardly verified via the __has_attribute macro. Introducing a
new attribute also avoids concerns about the potential incompatibility
with GCC's "malloc" semantics.

In future commits, codegen can be improved to recognize the noalias-ness
of the pointer returned inside a span-like struct.

This change helps unlock the alloc token instrumentation for such
non-standard allocation functions:

https://clang.llvm.org/docs/AllocToken.html#instrumenting-non-standard-allocation-functions

Fixes #167247

--- 

This PR addresses a case where Clang emitted `-Wmissing-noreturn` for
virtual methods whose body consists of a `throw` expression

```cpp
struct Base {
  virtual void foo() {
    throw std::runtime_error("error");
  }
};
```

Previously, the handling of the `cleanup` attribute had some checks
based on the type, but we were deducing the type after handling the
attribute.
This PR fixes the way the are dealing with type checks for the `cleanup`
attribute by delaying these checks after we are deducing the type.

It is also fixed in a way that the solution can be adapted for other
attributes that does some type based checks.
This is the list of C/C++ attributes that are doing type based checks
and will need to be fixed in additional PRs:
- CUDAShared
- MutualExclusions
- PassObjectSize
- InitPriority
- Sentinel
- AcquireCapability
- RequiresCapability
- LocksExcluded
- AcquireHandle

NB: Some attributes could have been missed in my shallow search.

Fixes #129631

Add a new builtin function __builtin_bswapg. It works on any integral
types that has a multiple of 16 bits as well as a single byte.

Closes #160266