Using `07` is a neat pun, but it not friendly to the reader. If the reader naively copies it and then changes the `7` to an `8` or a `9`, it will fail compilation: `invalid digit ... in octal constant`. Best avoided. Note that the other examples do not use octal literals.

PiperOrigin-RevId: 621335289
Change-Id: I6b11a639c5ba675eb29467baf45996ceff0ed9bf

PiperOrigin-RevId: 621258501
Change-Id: Id094f3f0d0bc4a9fa8f3d1f90cfcd4c53beeb776

This helps compilers that understand `ABSL_ATTRIBUTE_LIFETIME_BOUND` flag constructs such as
`absl::StatusOr<std::string_view> str = std::string(...)`
as error-prone.

PiperOrigin-RevId: 621196818
Change-Id: I78d4c66854cde9d06eaaec05869d956376109d9c

This helps compilers that understand `ABSL_ATTRIBUTE_LIFETIME_BOUND` flag constructs such as
`absl::StatusOr<std::string_view> str = std::string(...)`
as error-prone.

PiperOrigin-RevId: 621169918
Change-Id: Id621f63b9da4dc72eb4bd42c62d88bcc15a05243

PiperOrigin-RevId: 621169753
Change-Id: Ib6d7b248e14f29f1f91c24b8e1cf9703962b0e36

PiperOrigin-RevId: 621155521
Change-Id: I1705451bc1b931bfae3e1a2977bc56127e15faed

This will helps compilers that understand `ABSL_ATTRIBUTE_LIFETIME_BOUND` flag constructs such as
`absl::StatusOr<std::string_view> str = std::string(...)`
as error-prone.

For standard types, this is done via specializing the type traits.
For all other types, this is done by detecting the presence of a Boolean member trait such as:
`using absl_internal_is_view = std::true_type;`
in the type.

This is purely intended as a safety feature, and the values of these traits (even if wrong!) must NOT be depended on for correct behavior.
Furthermore, only high-value types (such as `absl::StatusOr`) are the intended users here.
Do not declare or use these traits on arbitrary types that are unlikely to be misused.

Do not depend on any of these to be stable, as they not (yet) public APIs.
Moreover, the trait declarations and mechanisms are all subject to change.
(For example, if `[[clang::lifetimebound]]` becomes possible to detect directly, the traits may need to be altered to utilize that, and distinguish between assignments and constructions.)

Should these or similar APIs be made public at a later point, the detection mechanisms may be altered quickly, and may (either loudly or silently) break existing code depending on these internal APIs without notice.

PiperOrigin-RevId: 620868493
Change-Id: I4a528a1dcf0df6ffbc3641d09537bc4c674aee4e

PiperOrigin-RevId: 620141661
Change-Id: I9dc9243b1d227f7cf32319bc1fec94aba850d4c1

This function previously returned true whenever the signal stack had unknown
bounds, that is obviously incorrect.

PiperOrigin-RevId: 620084964
Change-Id: I3821730b45773300569b9cbdb7e72442ed109d04

PiperOrigin-RevId: 619984581
Change-Id: I68fc9d6e9dd447bdccdbfd270073e11865f85965

No functional change.

PiperOrigin-RevId: 619979819
Change-Id: I71a4ae14272bcdf1da2e201ed286f95213ecb5e2

It took me way too much time to figure out why parameters of `absl::LogUniform` have nothing to do with the contents of the linked wiki page.

The new link does not match the function exactly, but it is still much closer than the log-normal distribution.

PiperOrigin-RevId: 619749575
Change-Id: Idbe748ed0dadf3ca22dc592f296f770ce04de8be

This CL contains two optimizations that were measured together.

1) InsertMiss (i. e. successful insert) optimization:
The idea that in case there is no kDeleted, we already know 99% of the information. So we are finding the position to insert with 2 asm instructions (or 3 in case of ARM or portable) and passing that as a hint into `prepare_insert`.

`prepare_insert` is out of the line in order to minimize effect on InsertHit (the most important case). `prepare_insert` may use the hint in case we still have growth and no kDeleted is guaranteed.

In case of kDeleted, we still call `find_first_non_full` in order to potentially find kDeleted slot earlier. We may consider different ways to do it faster for kDeleted later.

2) `find_first_non_full` optimization:

After optimization #1 `find_first_non_full` is used:
1. during resize and copy
2. right after resize
3. during DropDeletedWithoutResize
3. in InsertMiss for tables with kDeleted

In cases 1-3 the table is quite sparse.

1. After resize it is 7/16 sparse
2. During resize it is 7/16 maximum, but during first inserts it is much sparser.
3. During copy it may be up to 7/8, but at the beginning it is way sparser.
4. During DropDeletedWithoutResize it is 25/32 sparse, but at the beginning it is way sparser.

The only case, where the table is not known to be sparse, with `find_first_non_full` usage is a table with deleted elements. But according to hashz, we have <3% such tables. Adding an extra branch wouldn't hurt much there.

PiperOrigin-RevId: 619681885
Change-Id: Id3e2852cc6d85f6c8f90982d7aeb14799696bf39

PiperOrigin-RevId: 619649335
Change-Id: I8b3380816418a363fb6686db7966248cb530c491

PiperOrigin-RevId: 619598530
Change-Id: Ie4b808a3b826db8c271c81914c7a88d2c6216eb2

This change will allow the AVX version of non-temporal memcpy to be compiled
even if the compiler isn't run with AVX support. This allows runtime dispatch
to select the AVX implementation for CPUs that are known to be compatible with
AVX instructions.

PiperOrigin-RevId: 619594422
Change-Id: Ia7d92404ef8d10d152030b29b71948ed954f28f5

PiperOrigin-RevId: 619563536
Change-Id: I81df471817ddd4aba5aaa525adcdae5e7e03b886

ENOSTR, ETIME, ENODATA, and ENOSR are deprecated by POSIX and C++23.

This change also turns on the deprecation warnings used by Chromium.

See also:
https://wg21.link/LWG3869
https://github.com/llvm/llvm-project/pull/80542
https://buganizer.corp.google.com/issues/331100926

PiperOrigin-RevId: 619551374
Change-Id: Ica8d5008cbee52ce88d58a1fcb79dbe794045bae

The motivation is to use presence of kDeleted slots for optimizing InsertMiss for tables without kDeleted slots.

PiperOrigin-RevId: 619411282
Change-Id: Icc30606374aba7ce60b41f93ee8d44894e1b8aa5

See [implementation commit](https://github.com/abseil/abseil-cpp/commit/1449c9a106b090f61441ba245c781d7d2f89000c) for design details.

PiperOrigin-RevId: 619309882
Change-Id: I093c00365dda2268be86ba3d21421b6ffb59a5ce

Motivation: there are new uninitialized memory warnings when we enable small object optimization.
PiperOrigin-RevId: 619295212
Change-Id: If10762bab0e43c9619fc03f6d1eef5b8836bbf9a

Often code needs to know that it's built with sanitizers.
There are two common use for such information:
1. Work around incompatibility with sanitizers
2. Use sanitizers for more aggressive bug detection

With the current `ABSL_HAVE_*_SANITIZER` we can't distinguish
this two cased, and we didn't need that before.

Now user can define `NDEBUG_SANITIZER` to ask code like this
to avoid unnecessary checks.

I am not 100% sure that `NDEBUG` is not enough.
However relying on `NDEBUG` today will relax many tests, which
runs in NDEBUG mode only. So new `NDEBUG_SANITIZER` is safer
approach.

PiperOrigin-RevId: 619268413
Change-Id: I58185cd6886593a3742b8424deccdec366c2a35a

PiperOrigin-RevId: 619261152
Change-Id: Id3409b326c52ace0fda42537e0b91dbb2d6a2287

`MaybeRemoveEmptyCrcNode()`. Otherwise appending a `CordBuffer` an empty Cord
with a CRC node crashes (`RemoveCrcNode()` which increases the refcount of a
nullptr child).

Cosmetics: in `Cord::InlineRep::AppendArray()`, return early for empty `src`
before removing the empty CRC node.
PiperOrigin-RevId: 619107278
Change-Id: I4f1bc6b75c662f4678c61e3ef310e8597d62e2e1

PiperOrigin-RevId: 618970135
Change-Id: Ifb9d0b425904d5cb37d80ec28ab7845957209313

This can identify situations where flat_hash_* is suboptimal for large
elements.

PiperOrigin-RevId: 618937993
Change-Id: I2bde069bc3526b14ad1718ba6f50467002aeed16

PiperOrigin-RevId: 618872032
Change-Id: I9fdfadff906494eb64cee976c02a1fff57923c79

PiperOrigin-RevId: 618650101
Change-Id: I6cff17a9db0dc45ad3b1f833df6ea3d7d04a7449

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

Starting with Linux 6.6 [1], RDCYCLE is a privileged instruction on RISC-V and can't be used directly from userland. There is a sysctl option to change that as a transition period, but it will eventually disappear.

The RDTIME instruction is another less accurate alternative, however its frequency varies from board to board, and there is currently now way to get its frequency from userland [2].

Therefore this patch just removes the code for unscaledcycleclock on RISC-V. Without processor specific implementation, abseil relies on std::chrono::steady_clock::now().time_since_epoch() which is basically a wrapper around clock_gettime (CLOCK_MONOTONIC), which in turns use __vdso_clock_gettime(). On RISC-V this VDSO is just a wrapper around RDTIME correctly scaled to use nanoseconds units.

This fixes the testsuite on riscv64, tested on a VisionFive 2 board.

[1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=cc4c07c89aada16229084eeb93895c95b7eabaa3
[2] https://github.com/abseil/abseil-cpp/pull/1631
Merge 43356a2548cfde76e164d446cb69004b488c6a71 into 76f8011b

Merging this change closes #1644

COPYBARA_INTEGRATE_REVIEW=https://github.com/abseil/abseil-cpp/pull/1644 from aurel32:rv64-no-unscaledcycleclock 43356a2548cfde76e164d446cb69004b488c6a71
PiperOrigin-RevId: 618286262
Change-Id: Ie4120a727e7d0bb185df6e06ea145c780ebe6652

Having DLOG(FATAL) be [[noreturn]] in debug builds makes dead-code
warnings impossible to satisfy between the release and debug build.

PiperOrigin-RevId: 618257732
Change-Id: Ib1c2cb6a026401fbaa0a6e0770adfc166b964ece

PiperOrigin-RevId: 617920100
Change-Id: I0717560a88d32c067ce26b463b14d0db458b28b6

PiperOrigin-RevId: 617877687
Change-Id: I29c52f9288f099255c4adb7c1f9fa8831ac55b05

Code below those comments does use ElementType.

PiperOrigin-RevId: 617854731
Change-Id: I7996b8cbaa2fb65855a801f634a57d821408b1f3

PiperOrigin-RevId: 617613544
Change-Id: I526b5bc087edf54046c77795dddf5412478ac6a8

PiperOrigin-RevId: 617573381
Change-Id: I0ddab2ab7cf68651424b3cf385b484d27106dd59

Consistent with std::aligned_storage_t, it is deprecated in C++23.

https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2021/p1413r3.pdf
has a suggested replacement

PiperOrigin-RevId: 617367005
Change-Id: I009533c5609c8ffd77e406e1fc88e51a3ce99f9f

PiperOrigin-RevId: 617266753
Change-Id: I6cac7b4616001c8d435fb1786da81b746f2d14cb

Fixes #1636 (GCC -Wmaybe-uninitialized warning)

PiperOrigin-RevId: 617253727
Change-Id: I246cd21d8123d4dfa7780b1c4cac8ea1558a4067

When sampling triggers, we skip SOO and allocate a backing array. We must do this because the HashtablezInfoHandle is part of the heap allocation (along with the control bytes and slots). By default, we sample 1 in ~1024 hashtables when sampling is enabled. This will impact performance because (a) we won't benefit from SOO so we would have worse data locality (more cache/TLB misses), and (b) the backing array capacity will be 3 instead of 1 so (b.1) we skip the rehash after the second insertion and (b.2) we potentially waste up to two slots worth of memory.

We also add an soo_capacity field to HashtablezInfo to allow for distinguishing which sampled tables may otherwise have been SOO - this will allow us to know approximately what fraction of tables are in SOO mode.

PiperOrigin-RevId: 617252334
Change-Id: Ib48b7a4870bd74ea3ba923ed8f350a3b75dbb7d3

Add explicit #include directives for <tuple>, "absl/base/config.h", and "absl/strings/string_view.h".

PiperOrigin-RevId: 617232899
Change-Id: I5e6c0bd4545d7f7ad9c5c494017269e247f620a3