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.

We can use non-owning `StringRef` in `MacroName` parameter to avoid
unnecessary copy because `MacroName` only used as an argument to
`internal::getExpansionLocOfMacro` which already accept `StringRef`.

…nd update docs

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)

Document a define to allow library developers to support disabling 
AddressSanitizer's container overflow detection in template code at 
compile time.

The primary motivation is to reduce false positives in environments
where
libraries and frameworks that cannot be recompiled with sanitizers
enabled
are called from application code. This supports disabling checks when
the
runtime environment cannot be reliably controlled to use ASAN_OPTIONS.

Key changes:
- Use the define `__SANITIZER_DISABLE_CONTAINER_OVERFLOW__` to disable
  instrumentation at compile time
- Implemented redefining the container overflow APIs in
common_interface_defs.h
  to use define to provide null implementation when define is present
- Update documentation in AddressSanitizer.rst to suggest and illustrate
  use of the define
- Add details of the define in PrintContainerOverflowHint()
- Add test disable_container_overflow_checks to verify new hints on the
error and fill the testing gap that
ASAN_OPTIONS=detect_container_overflow=0
  works
- Add tests demonstrating the issue around closed source libraries and 
  instrumented apps that both modify containers

This requires no compiler changes and should be supportable cross
compiler toolchains.

An RFC has been opened to discuss: 

https://discourse.llvm.org/t/rfc-add-fsanitize-address-disable-container-overflow-flag-to-addresssanitizer/88349

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