Some compilers warn if a switch block that already covers all
enumeration values also has a default label.

PiperOrigin-RevId: 597583941
Change-Id: Ib3eb08dca0a19105522c61e47944cfc75280c15e

PiperOrigin-RevId: 597297788
Change-Id: Idb4cd3f62a03204bcad423d9934963136c018996

f845e60a added an option to use C++20's
<ordering> header but the CMake install configured this as an alias
in C++17 when it is not available.

Fixes #1597

PiperOrigin-RevId: 597258569
Change-Id: I40277d55702601e1686370bee6af9b7491fd2000

releasing Abseil and GoogleTest.

GoogleTest referenced this internal file and this internal trait.  Since
simultaneous releases are not possible since once release must reference
another, we will temporarily add this back.
https://github.com/google/googletest/blob/v1.14.x/googletest/include/gtest/gtest-printers.h#L119

https://github.com/google/googletest/pull/4368#issuecomment-1717699895
https://github.com/google/googletest/pull/4368#issuecomment-1717699895

PiperOrigin-RevId: 597073935
Change-Id: I7c2697a212dc477fd25770777445c64cfee73745

This changes the way in which clang-cl is selected on Windows
as it has changed:
https://bazel.build/configure/windows#clang

--features=external_include_paths has been removed from Windows builds
since it appears cause build command errors currently
PiperOrigin-RevId: 596965732
Change-Id: I95b636a9a4fdcc4172c3bb8c6cb28d5f7db592c9

This follows Benford's law, which is likely also a much more accurate representation of real data than a constant.

We also add benchmarks for different integer types.

PiperOrigin-RevId: 596039508
Change-Id: I4862c7cfdbf5face18ae31cf0bd2fd54e47684b7

The updated code is designed to:
- Be branch-predictor-friendly
- Be cache-friendly
- Minimize the lengths of critical paths
- Minimize slow operations (particularly multiplications)
- Minimize binary/codegen bloat

The most notable performance trick here is perhaps the precomputation & caching of the number of digits, so that we can reuse/exploit it when writing the output.

This precomputation of the exact length enables 2 further performance benefits:
- It makes `StrCat` and `StrAppend` zero-copy when only integers are passed, by avoiding intermediate `AlphaNum` entirely in those cases. If needed in the future, we can probably also make many other mixtures of non-integer types zero-copy as well.
- It avoids over-reservation of the string buffer, allowing for more strings to fit inside SSO, which will likely have further performance benefits.

There is also a side benefit of preventing `FastIntToBuffer` from writing beyond the end of the buffer, which has caused buffer overflows in the past.

The new code continues to use & extend some of the existing core tricks (such as the division-by-100 trick), as those are already efficient.

PiperOrigin-RevId: 595785531
Change-Id: Id6920e7e038fec10b2c45f213de75dc7e2cbddd1

Neither GCC nor Clang's __builtin_nan(), nor glibc's nan(), accept null pointers.

PiperOrigin-RevId: 595767225
Change-Id: I4cddd1cafd0c9e83a823ec68386f10ce077c6b4c

https://github.com/abseil/abseil-cpp/issues/1465 reports that
some CMake builds on Apply platforms issue

```
warning: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ranlib: archive library: libabsl_bad_any_cast_impl.a the table of contents is empty (no object file members in the library define global symbols)
```

Our CMake build handles this problem for header-only libraries by not
building a library at all. For some libraries, for example our polyfills,
the library is only conditionally empty. In these libraries, I added
a single char variable on Apple platforms as a workaround.

I have been able to reproduce the warnings reported in
https://github.com/abseil/abseil-cpp/issues/1465, but they don't fail the
build for me. I don't see them any more after this change.

PiperOrigin-RevId: 595480705
Change-Id: Ie48637e84ebae2f2aea4e2de83b146f30f6a76b9

Speed up `raw_hash_set::contains()` when ABSL hardening is enabled by removing the iterator invalidation check from the comparison that contains performs.

PiperOrigin-RevId: 595460301
Change-Id: I9a5d6c81385e38184f4848c58209adc5d32bb7be

constexpr Flag construction. These versions of MSVC are no longer
supported.

PiperOrigin-RevId: 595195773
Change-Id: Iaf2f01a2255fb24f3aadc26f09600543fffa9da5

Imported from GitHub PR https://github.com/abseil/abseil-cpp/pull/1589

It makes sense because even if it fails spuriously, we can just try again since we have to check for other readers anyway.
Merge 0b1780299b9e43205202d6b25f6e57759722d063 into 6a19ff47

Merging this change closes #1589

COPYBARA_INTEGRATE_REVIEW=https://github.com/abseil/abseil-cpp/pull/1589 from AtariDreams:atomics 0b1780299b9e43205202d6b25f6e57759722d063
PiperOrigin-RevId: 595149382
Change-Id: I24f678f6bf95c6a37b2ed541a2b6668a58a67702

PiperOrigin-RevId: 595114487
Change-Id: Ia8fc94e4feaf8da1185e7e93ba4250e61e690cfd

* Also does this for `absl::internal::identity_t` which is now `absl::internal::type_identity_t`
* This is clearer naming as this is a backfill of `std::type_identity` (the identity type), and not `std::identity` (the identity function)

PiperOrigin-RevId: 594316002
Change-Id: I5fb8cf7e3d07c1bc736cbecd202e7d556b6ea33e

Add compile-checks to ensure the parameter to absl::numbers_internal::FastIntToBuffer isn't provably insufficient

This performance-sensitive API is internal, and should not be used directly. Nevertheless, some do use it, so it's worth trying to block incorrect uses where we can.

PiperOrigin-RevId: 594289730
Change-Id: Ib5df39b450ef2ceda795082cde10ec2ba2642172

PiperOrigin-RevId: 593918110
Change-Id: Ide100c69b10e28011af17c7f82bb10eea072cad4

PiperOrigin-RevId: 593889663
Change-Id: I589cd18922172d8aca99ddcc0d6f08a013bed9b4

PiperOrigin-RevId: 593814844
Change-Id: If1967814b2b9273061b928bfee102faae1fad263

PiperOrigin-RevId: 593780380
Change-Id: Id80217c63dd76bafbcfb79a7ee10807f1b771cb2

PiperOrigin-RevId: 592918704
Change-Id: Iacef0e069c012a04960211c032454244822f9634

PiperOrigin-RevId: 592864147
Change-Id: I83179b0225aa446ae0b57b46b604af14f1fa14df

PiperOrigin-RevId: 592664369
Change-Id: I7aa7b045c2b3c0f25cff7b82eb9d9cc13e9fc49f

PiperOrigin-RevId: 592653487
Change-Id: Iddd2f484807cb02dd2ee8bba26c22d196be02c88

Linux kernel's rt_sigprocmask correctly handles an unaligned user address[1].
The original issue was for qemu-user, which seems long irrelevant.

Tested locally on an AArch64 CPU and qemu-aarch64-static.

The alignment operation actually serves another purpose: when addr resides in
the last 7 bytes of a page (unaligned), check only the current page and not the
next. Update the comment.

[1]:
kernel/signal.c `SYSCALL_DEFINE4(rt_sigprocmask`
arch/arm64/include/asm/uaccess.h:raw_copy_from_user
arch/arm64/lib/copy_template.S  "alignment handled by the hardware"

PiperOrigin-RevId: 592618320
Change-Id: Ifbd05aba42f46e36e710cca940570213036b3ce0

We currently have a workaround for MSVC, which has constexpr pointer arithmetic bugs. The bug seems to still exist and the existing code for non-MSVC compilers doesn't build.

This alternative constexpr constructor avoids pointer arithmetic and seems to be working for all, including MSVC.

PiperOrigin-RevId: 592586957
Change-Id: Ic585693c3a7abaab5fbbc0954b8ee924994f8dbf

PiperOrigin-RevId: 592483250
Change-Id: I55fa9982c4dbc723b30957cb31da95251e368707

PiperOrigin-RevId: 592390284
Change-Id: If5b612a3f8d3144df108deb4ee28c1e9279b858b

PiperOrigin-RevId: 592337948
Change-Id: I373943b8daf28781e063b302fc916ca5644e8fe1

PiperOrigin-RevId: 592301543
Change-Id: I97e4df805c7313896228430a50a7f991127f3e30

PiperOrigin-RevId: 592272653
Change-Id: I895c5786555227bdc88ab0a4cce8cf5ba65222a1

use Bazel 7.0.0.

CMake is also updated to 3.28.1

PiperOrigin-RevId: 592263272
Change-Id: I4daccdad4bceb483b0400328baebc79591990328

The added test exposes a false TSan race report in
EnableInvariantDebugging/EnableDebugLog related to SynchEvent reuse.

We ignore most of the stuff that happens inside of the Mutex code,
but not for the code inside of EnableInvariantDebugging/EnableDebugLog.
So these can cause occasional false reports on SynchEvent bankruptcy.

Also ignore accesses in EnableInvariantDebugging/EnableDebugLog.

PiperOrigin-RevId: 592226791
Change-Id: I066edb1ef5661ba6cf86a195f91a9d5328b93d10

PiperOrigin-RevId: 591987002
Change-Id: Ic1ed2063aeb95a6e814eefcbed024e1a5a1d8d2f

Previously, `absl::Condition` incorrectly used the same (non-`const`)
pointer-to-method type when wrapping both `const` and non-`const` methods.

Unfortunately, this is undefined behavior according to `[expr.reinterpret.cast]`
in the C++ standard:

> The effect of calling a function through a pointer to a function type that is
> not the same as the type used in the definition of the function is undefined.

This fixes the UB.

PiperOrigin-RevId: 591981682
Change-Id: Iaca955346699417232383d3a1800ea9b82ea5761

PiperOrigin-RevId: 591928115
Change-Id: I55de0886d3ce2d58cc1c94a15ce0f3eefc5eeaaf

PiperOrigin-RevId: 591894838
Change-Id: Ib3fe72d255f49320e2728c210ba1faabc81e0ef8

These are in some sense correct (begin()/end() can be null for empty spans), but
don't capture the critical contract that begin() is only null when end() is.
This leads to foreach loops over spans being considered unsafe.

Long-term we may want to express such constraints somehow, but for now giving
these pointers unknown nullability is the best we can do.

PiperOrigin-RevId: 591191038
Change-Id: I1f02e068a445c0ca5996a9212477b64393ef4161

PiperOrigin-RevId: 591161019
Change-Id: Iae2477a24819e20288fbb83b4a343031af71f1bb

PiperOrigin-RevId: 591015112
Change-Id: I3e654433f0b0a4ea02ee10e0894e70738e730782

PiperOrigin-RevId: 590669848
Change-Id: Ibc703b0fbedede86ddaa9682049b7dcc2250fbfb