It adds the missing member functions of the tzdb class and adds the free
functions that use these member functions.

Implements parts of:
- P0355 Extending <chrono> to Calendars and Time Zones

This implements the loading of the leap-seconds.list file and store its
contents in the tzdb struct.

This adds the required `leap_seconds` member.

The class leap_seconds is fully implemented including its non-member
functions.

Implements parts of:
- P0355 Extending <chrono> to Calendars and Time Zones
- P1614 The Mothership has Landed

Implements:
- P1981 Rename leap to leap_second
- LWG3359 <chrono> leap second support should allow for negative leap seconds
- LWG3383 §[time.zone.leap.nonmembers] sys_seconds should be replaced with seconds

This reverts commit b61fb184.

This commit landed with build failures in the pre-commit CI
https://buildkite.com/llvm-project/libcxx-ci/builds/34153

Right now the algorithm does not exit on unpredictable values. It
waits until all the paths have been enumerated to see if any of
those paths have that value. Waiting this late leads to a lot of
wasteful computation and higher compile time.

In this patch I have added a heuristic that checks if the value
comes from the same inner loops as the switch, if so, then it is
likely that the value will also be seen on a threadable path and
the code in `getStateDefMap()` return an empty map.

I tested this on the llvm test suite and the only change in the
number of threaded switches was in 7zip (before 23, after 18).
In all of those cases the current algorithm was partially threading
the loop because it was hitting a limit on the number of paths to
be explored. On increasing this limit even the current algorithm
finds paths where the unpredictable value is seen.

Compile time(with pass enabled by default and this patch):

https://llvm-compile-time-tracker.com/compare.php?from=8c5e9cf737138aba22a4a8f64ef2c5efc80dd7f9&to=42c75d888058b35c6d15901b34e36251d8f766b9&stat=instructions:u

This adds basic support for calling the verifier on global declarations
that are expected to represent symbol exports. The driver now
exclusively uses this for knowing what symbols make up a TBD file.
Future patches will check against the dylib's symbol table.

* A lot of `tapi installapi` options are already shared with clang, but
not all. This patch handles installapi-specific options by filtering for
them in the initial argv input, then passing the rest to the clang
driver.
* Installapi not only generates a text file but also reports to library
developers when there are inconsistencies between an interface and its
implementation. To allow this, add support for reporting installapi
diagnostics. This will be leveraged in the verifier service.

I accidentally removed this transitive include in #85478.

Fixes #85519.

For Mach-O, ld64 supports the -fobjc-relative-method-lists flag which
changes the format in which method lists are generated. The format uses
delta encoding vs the original direct-pointer encoding.
This change adds support to llvm-objdump and llvm-otool for
decoding/dumping of method lists in the delta format. Previously, if a
binary with this information format was passed to the tooling, it would
output invalid information, trying to parse the delta lists as pointer
lists.
After this change, the tooling will output correct information if a
binary in this format is encountered.
The output format is closest feasible match to XCode 15.1's otool
output. Tests are included for both 32bit and 64bit binaries.

The code style was matched as close as possible to existing
implementation of parsing non-delta method lists.

Diff between llvm-objdump and XCode 15.1 otool:

![image](https://github.com/llvm/llvm-project/assets/103613512/2277e3ff-d59c-4fff-b93a-e0587ee740a6)

Note: This is a retry of this PR:
https://github.com/llvm/llvm-project/pull/84250


On the original PR, the armv7+armv8 builds were failing due to absolute
offsets being different.

Co-authored-by: Alex B <alexborcan@meta.com>

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