Reverts llvm/llvm-project#84626

This reduces the include time from 767ms to 691ms.

Implements [P2602R2 Poison Pills are Too
Toxic](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2022/p2602r2.html)
as a DR in C++20 mode.

This re-applies #74110 with the crashing code disabled in C++11. I'll
try to fix the new crash in it's own patch.

This reverts commit dec63221.

This probably needs more discussion before we can land it. The consensus
(from what I can gather) in https://discourse.llvm.org/t/rfc-clang-format-all-the-things/76614
is that we should be careful with version upgrades for consistency.

This reverts commit c69ec700, which has been
obsolete since commit dec63221 because the clang-format style was added
in version 18.

Various (in-tree as well as downstream) targets currently depend on
`InliningUtils.h` to avoid circular dependencies. E.g. `TransformUtils`
depends on `ArithDialect`, so `ArithDialect` can't depend on
`TransformUtils` exporting `InliningUtils.h`. This change exposes that
header and it's implementation as a separate target. Having targets that
implement all the declared functions is the preferred approach for bazel
build graphs.

See also PR #84878, which moves the interface definitions to a separate
file in the `Interfaces` directory. This turned out to be controversial
and putting it in a different directory didn't seem to have any support
either. Instead, this PR only changes the bazel build without moving any
C++ code.

See
https://github.com/llvm/llvm-project/commit/0a739eb75fe68b1cec4e4aaad8b5395bb5da9a89#commitcomment-139850284

[Concepts] Add Decls from the outer scope of the current lambda for conversion function constraints (#83420)

This fixes the case shown by
https://github.com/llvm/llvm-project/issues/64808#issuecomment-1929131611.

Similar to
https://github.com/llvm/llvm-project/commit/f9caa12328b265b77221fe7a310d4504673d814a

,
we have some calls to constraint checking for a lambda's conversion
function while determining the conversion sequence.

This patch addresses the problem where the requires-expression within
such a lambda references to a Decl outside of the lambda by adding these
Decls to the current instantiation scope.

I'm abusing the flag `ForOverloadResolution` of
CheckFunctionConstraints, which is actually meant to consider the Decls
from parent DeclContexts.

---------

Co-authored-by: cor3ntin <corentinjabot@gmail.com>

Some targets have passes with parameters, e.g. ARM, AMDGPU and MIPS.
For example, AMDGPU has a pass `AMDGPUAtomicOptimizerPass`
which need a `ScanOption`, this commit enables the syntax
like `-passes=amdgpu-atomic-optimizer<strategy=dpp>` for backend passes.

Buffers are no longer deallocation by One-Shot Bufferize. This is now
done by a separate buffer deallocation pass.

Also fix a bug in the `vector.mask` folding, which was triggered by
`-buffer-deallocation-pipeline`, which runs the canonicalizer.

This PR adds promised interface declarations for all interfaces declared
in `InitAllDialects.h`.

Promised interfaces allow a dialect to declare that it will have an
implementation of a particular interface, crashing the program if one
isn't provided when the interface is used.

Change `memref.alloc` to `memref.alloca`, which does not require manual
deallocation.

A name is not a FunctionDeclarationName if it's preceded by an
Objective-C keyword.

Fixes #84578.

closes #70071
- `CGBuiltin.cpp` - Add the unsigned\generic clamp intrinsic emitter.
- `IntrinsicsDirectX.td` - add the `dx.clamp` & `dx.uclamp` intrinsics
- `DXILIntrinsicExpansion.cpp` - add the `clamp` instruction expansion
while maintaining vector form.
- `SemaChecking.cpp` -  Add `clamp`  builtin Sema Checks.
- `Builtins.td` - add a `clamp` builtin
- `hlsl_intrinsics.h` - add the `clamp` api

Why `clamp` as instruction expansion  for DXIL?
1. SPIR-V has a GLSL `clamp` extension via:
-
[FClamp](https://registry.khronos.org/SPIR-V/specs/1.0/GLSL.std.450.html#FClamp)
-
[UClamp](https://registry.khronos.org/SPIR-V/specs/1.0/GLSL.std.450.html#UClamp)
-
[SClamp](https://registry.khronos.org/SPIR-V/specs/1.0/GLSL.std.450.html#SClamp)
2. Further Clamp lowers to `min(max( x, min_range ), max_range)` which
we have float, signed, & unsigned dixilOps.

Reverts llvm/llvm-project#85030

This patch causes build failures when building runtimes for armv6m
```
FAILED: /b/s/w/ir/x/w/llvm_build/include/armv6m-unknown-eabi/stdlib.h 
cd /b/s/w/ir/x/w/llvm-llvm-project/libc/include && /b/s/w/ir/x/w/llvm_build/bin/libc-hdrgen -o /b/s/w/ir/x/w/llvm_build/include/armv6m-unknown-eabi/stdlib.h --header stdlib.h --def /b/s/w/ir/x/w/llvm-llvm-project/libc/include/stdlib.h.def -I /b/s/w/ir/x/w/llvm-llvm-project/libc --e=__assert_fail --e=isalnum --e=isalpha --e=isascii --e=isblank --e=iscntrl --e=isdigit --e=isgraph --e=islower --e=isprint --e=ispunct --e=isspace --e=isupper --e=isxdigit --e=toascii --e=tolower --e=toupper --e=__stack_chk_fail --e=errno --e=bcmp --e=bcopy --e=bzero --e=index --e=memccpy --e=memchr --e=memcmp --e=memcpy --e=memmem --e=memmove --e=mempcpy --e=memrchr --e=memset --e=memset_explicit --e=rindex --e=stpcpy --e=stpncpy --e=strcasecmp --e=strcasestr --e=strcat --e=strchr --e=strchrnul --e=strcmp --e=strcoll --e=strcpy --e=strcspn --e=strerror --e=strerror_r --e=strlcat --e=strlcpy --e=strlen --e=strncasecmp --e=strncat --e=strncmp --e=strncpy --e=strnlen --e=strpbrk --e=strrchr --e=strsep --e=strspn --e=strstr --e=strtok --e=strtok_r --e=strxfrm --e=imaxabs --e=imaxdiv --e=strtoimax --e=strtoumax --e=sprintf --e=snprintf --e=vsprintf --e=vsnprintf --e=stdc_leading_zeros_uc --e=stdc_leading_zeros_us --e=stdc_leading_zeros_ui --e=stdc_leading_zeros_ul --e=stdc_leading_zeros_ull --e=stdc_leading_ones_uc --e=stdc_leading_ones_us --e=stdc_leading_ones_ui --e=stdc_leading_ones_ul --e=stdc_leading_ones_ull --e=stdc_trailing_zeros_uc --e=stdc_trailing_zeros_us --e=stdc_trailing_zeros_ui --e=stdc_trailing_zeros_ul --e=stdc_trailing_zeros_ull --e=stdc_trailing_ones_uc --e=stdc_trailing_ones_us --e=stdc_trailing_ones_ui --e=stdc_trailing_ones_ul --e=stdc_trailing_ones_ull --e=stdc_first_leading_zero_uc --e=stdc_first_leading_zero_us --e=stdc_first_leading_zero_ui --e=stdc_first_leading_zero_ul --e=stdc_first_leading_zero_ull --e=stdc_first_leading_one_uc --e=stdc_first_leading_one_us --e=stdc_first_leading_one_ui --e=stdc_first_leading_one_ul --e=stdc_first_leading_one_ull --e=stdc_first_trailing_zero_uc --e=stdc_first_trailing_zero_us --e=stdc_first_trailing_zero_ui --e=stdc_first_trailing_zero_ul --e=stdc_first_trailing_zero_ull --e=stdc_first_trailing_one_uc --e=stdc_first_trailing_one_us --e=stdc_first_trailing_one_ui --e=stdc_first_trailing_one_ul --e=stdc_first_trailing_one_ull --e=stdc_count_zeros_uc --e=stdc_count_zeros_us --e=stdc_count_zeros_ui --e=stdc_count_zeros_ul --e=stdc_count_zeros_ull --e=stdc_count_ones_uc --e=stdc_count_ones_us --e=stdc_count_ones_ui --e=stdc_count_ones_ul --e=stdc_count_ones_ull --e=stdc_has_single_bit_uc --e=stdc_has_single_bit_us --e=stdc_has_single_bit_ui --e=stdc_has_single_bit_ul --e=stdc_has_single_bit_ull --e=stdc_bit_width_uc --e=stdc_bit_width_us --e=stdc_bit_width_ui --e=stdc_bit_width_ul --e=stdc_bit_width_ull --e=stdc_bit_floor_uc --e=stdc_bit_floor_us --e=stdc_bit_floor_ui --e=stdc_bit_floor_ul --e=stdc_bit_floor_ull --e=stdc_bit_ceil_uc --e=stdc_bit_ceil_us --e=stdc_bit_ceil_ui --e=stdc_bit_ceil_ul --e=stdc_bit_ceil_ull --e=abort --e=abs --e=atoi --e=atof --e=atol --e=atoll --e=bsearch --e=div --e=labs --e=ldiv --e=llabs --e=lldiv --e=qsort --e=qsort_r --e=rand --e=srand --e=strtod --e=strtof --e=strtol --e=strtold --e=strtoll --e=strtoul --e=strtoull --e=feclearexcept --e=fedisableexcept --e=feenableexcept --e=fegetenv --e=fegetexcept --e=fegetexceptflag --e=fegetround --e=feholdexcept --e=fesetenv --e=fesetexceptflag --e=fesetround --e=feraiseexcept --e=fetestexcept --e=feupdateenv --e=acosf --e=acoshf --e=asinf --e=asinhf --e=atanf --e=atanhf --e=ceil --e=ceilf --e=ceill --e=copysign --e=copysignf --e=copysignl --e=cosf --e=coshf --e=erff --e=exp --e=exp10 --e=exp10f --e=exp2 --e=exp2f --e=expf --e=expm1 --e=expm1f --e=fabs --e=fabsf --e=fabsl --e=fdim --e=fdimf --e=fdiml --e=floor --e=floorf --e=floorl --e=fma --e=fmaf --e=fmax --e=fmaxf --e=fmaxl --e=fmin --e=fminf --e=fminl --e=fmod --e=fmodf --e=fmodl --e=frexp --e=frexpf --e=frexpl --e=hypot --e=hypotf --e=ilogb --e=ilogbf --e=ilogbl --e=ldexp --e=ldexpf --e=ldexpl --e=llogb --e=llogbf --e=llogbl --e=llrint --e=llrintf --e=llrintl --e=llround --e=llroundf --e=llroundl --e=log --e=log10 --e=log10f --e=log1p --e=log1pf --e=log2 --e=log2f --e=logb --e=logbf --e=logbl --e=logf --e=lrint --e=lrintf --e=lrintl --e=lround --e=lroundf --e=lroundl --e=modf --e=modff --e=modfl --e=nan --e=nanf --e=nanl --e=nearbyint --e=nearbyintf --e=nearbyintl --e=nextafter --e=nextafterf --e=nextafterl --e=nexttoward --e=nexttowardf --e=nexttowardl --e=powf --e=remainder --e=remainderf --e=remainderl --e=remquo --e=remquof --e=remquol --e=rint --e=rintf --e=rintl --e=round --e=roundf --e=roundl --e=scalbn --e=scalbnf --e=scalbnl --e=sincosf --e=sinf --e=sinhf --e=sqrt --e=sqrtf --e=sqrtl --e=tanf --e=tanhf --e=trunc --e=truncf --e=truncl --e=abshk --e=abshr --e=absk --e=absr --e=abslk --e=abslr --e=exphk --e=expk --e=roundhk --e=roundhr --e=roundk --e=roundr --e=roundlk --e=roundlr --e=rounduhk --e=rounduhr --e=rounduk --e=roundur --e=roundulk --e=roundulr --e=sqrtuhk --e=sqrtuhr --e=sqrtuk --e=sqrtur --e=sqrtulr --e=uhksqrtus --e=uksqrtui /b/s/w/ir/x/w/llvm-llvm-project/libc/config/baremetal/api.td
error: __qsortrcompare_t not found in any standard spec.
```
Original failure:
https://ci.chromium.org/ui/p/fuchsia/builders/toolchain.ci/clang-linux-x64/b8753376051397217137/overview
I've tested that reverting this commit would make the build green again.

https://ci.chromium.org/raw/build/logs.chromium.org/fuchsia/led/paulkirth_google.com/29c31064b1fb757cb90a304e79086d644406406dff130569c2e77b066021eee6/+/build.proto?server=chromium-swarm.appspot.com

This change lifts the restriction that purely allocated empty sparse
tensors cannot escape the method. Instead it makes a best effort to add
a finalizing operation before the escape.

This assumes that
(1) we never build sparse tensors across method boundaries
    (e.g. allocate in one, insert in other method)
(2) if we have other uses of the empty allocation in the
    same method, we assume that either that op will fail
    or will do the finalization for us.

This is best-effort, but fixes some very obvious missing cases.

Since LLVM supports `-ffat-lto-objects` we should enable this as an
option in the LLVM build. FatLTO should improve the time it takes to
build tests for LTO enabled builds of the compiler by not linking w/ the
bitcode portion of the object files, which should speed up build times
for LTO builds without disabling optimizations.

llvm-project/mlir/lib/Target/LLVMIR/DebugTranslation.cpp:226:10:
error: unused variable '[iter, inserted]' [-Werror,-Wunused-variable]
    auto [iter, inserted] =
         ^
1 error generated.

Static local variables with dynamic initializers depend on implicitly defined
guard variables to synchronize thread-safe initialization.  These guard
variables may have external linkage and therefore require a stable name for
linkage purposes.  The Microsoft ABI assigns these variables a local name of
'$TSS' followed by a discriminator and mangles them as a static local variable
of type 'int'.  Previously, the '$TSS<discriminator>' portion of the name was
not registered as a back reference candidate and this resulted in incorrect
back references for enclosing class and/or namespace scopes that might be
referenced in the signature of the enclosing function.  This change adds the
previously missing back reference registration.  This matches the mangling
performed by MSVC and resolves incompatibilities when inline functions with
static local variables are inlined across DLL boundaries.

This is an ABI change and has the potential to cause backward compatibility
issues with previous Clang releases.

Fixes #83616

Move CCC_OVERRIDE_OPTIONS support to clangDriver so that it may be used outside of the 
clang driver binary.

The override functionality will be used in LLDB, to apply adjustments to ClangImporter 
flags. This will be useful as an escape hatch when there are issues that can be fixed 
by adding or removing clang flags.

The only thing changed is the name, from `ApplyQAOverride` to `applyOverrideOptions`.

`EvaluateExpression` does not always create a new persistent result. If the expression 
is a bare persistent variable, then a new persistent result is not created. This means 
the caller can't assume a new persistent result is created for each evaluation. 
However, `dwim-print` was doing exactly that: assuming a new persistent result for each 
evaluation. This resulted in a bug:

```
(lldb) p int $j = 23
(lldb) p $j
(lldb) p $j
```

The first `p $j` would not create a persistent result, and so `dwim-print` would 
inadvertently delete `$j`. The second `p $j` would fail.

The fix is to try `expr` as a persistent variable, after trying `expr` as a frame 
variable. For persistent variables, this avoids calling `EvaluateExpression`.

Resolves https://github.com/llvm/llvm-project/issues/84806

rdar://124688427

llvm-project/lldb/unittests/Host/AlarmTest.cpp:49:7:
error: 'lock_guard' may not intend to support class template argument deduction [-Werror,-Wctad-maybe-unsupported]
      std::lock_guard guard(m);
      ^

llvm-project/lldb/source/Host/common/Alarm.cpp:37:5:
error: 'lock_guard' may not intend to support class template argument deduction [-Werror,-Wctad-maybe-unsupported]
    std::lock_guard alarm_guard(m_alarm_mutex);
    ^

Summary:
This documentation was lagging reality and didn't contain much. Update
it with some more information now that it's more mature.

Followup to #85188.

This PR adds `-march=generic` support for the NVPTX backend. This
fulfills a TODO introduced in #79873.

With this PR, users can explicitly request the "default" CUDA
architecture, which makes sure that no specific architecture is
specified.

This PR does not address any compatibility issues between different CUDA
versions.

---------

Co-authored-by: Joseph Huber <huberjn@outlook.com>

This is another step towards supporting DWARF5 checksums and inline
source code in LLDB.

Clean-up to keep the type qualifier next to the type.

Reviewers: klausler

Reviewed By: klausler

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

[Clause representation 6/6]