proposed standard pthread_cond_clockwait() and sem_clockwait().
These are currently implemented in glibc >= 2.30.

These methods take a clock and use an absolute time with reference
to that clock, so KernelTimeout now can produce these values.

PiperOrigin-RevId: 522824226
Change-Id: Ife98713f6f95d800b1f8e52d5364a3dbebc4f8a6

PiperOrigin-RevId: 522411202
Change-Id: Ifc99f5f6a227efd697039344ea75f53c6f282e53

PiperOrigin-RevId: 522393331
Change-Id: Ia5f4ad6a2d16c033ea97f3c7e27e8eb7ee429242

PiperOrigin-RevId: 522392902
Change-Id: I5764edbe85612e90d02caae49bbf629dcb8879e3

using the non-portable pthread_cond_timedwait_relative_np()

PiperOrigin-RevId: 522340555
Change-Id: I08682f74d8d94965330f12274c7a92632b1a29f1

PiperOrigin-RevId: 521932692
Change-Id: If637de6501a4ac41f0078d581049d23aad3480a4

https://github.com/google/oss-policies-info/blob/main/foundational-cxx-support-matrix.md

PiperOrigin-RevId: 521573177
Change-Id: I1f12ddbd8516314ee2ed7f8ba6a6895b03c6c270

PiperOrigin-RevId: 521556211
Change-Id: I1e1812eb11bfc5772abbf38ce348580c3afa5612

were broken on MSVC 2017, but MSVC 2017 is no longer supported

PiperOrigin-RevId: 521527454
Change-Id: I7203708bdc9aa03c9764c9c36db7ce5777e43c3c

PiperOrigin-RevId: 521525676
Change-Id: I40083f534c6904b4823138666deac18ffe6deab6

PiperOrigin-RevId: 521450545
Change-Id: Ia4fe02a57d23411f0a80443c0ad89dfaf4117a37

PiperOrigin-RevId: 521133781
Change-Id: I1334ea683bc01ef9b1b9800d6681e29dd2a1ec55

We know that the elements are trivially destructible if this path is used, so
there is no need to call their destructors one by one.

PiperOrigin-RevId: 521088624
Change-Id: I3edff97a073770f99031eefa7a34968fad5d7880

The fact that this is called from paths where the element type may not have a
trivial destructor is preventing an optimization (see the TODO). Stop calling
from those paths so that the optimization can be made in an upcoming CL.

PiperOrigin-RevId: 521087730
Change-Id: Id2b66d8f36bb0d294784d0793fdd8f07e315739f

The copy constructor isn't doing or simulating copy assignment; nor is it
destroying anything. We don't need to require that those operations be trivial.

PiperOrigin-RevId: 521020499
Change-Id: I0f36a720384b333ea15e6c8275872fd4fd9a738f

PiperOrigin-RevId: 520955097
Change-Id: I50a19305aed2b60dea0293b1a2106673e4cb7756

PiperOrigin-RevId: 520925224
Change-Id: I8b7eb8b4d4b99d72b860aec532516b428fb2be23

PiperOrigin-RevId: 520724148
Change-Id: Ia90c4a711649e89454bc2ca0a9d0d771d56e79c0

This change fixes -Wimplicit-const-int-float-conversion warnings
by making the conversions explicit.

PiperOrigin-RevId: 520707623
Change-Id: Ib6917469120cd7458257195cbf39beb3fd397543

For function N in the stack, the current code reports the size of
frame N - 1. Fix that.

PiperOrigin-RevId: 520688072
Change-Id: I984729f72f79aebae1b6997cb51d3ddef9199d1e

These have nothing to do with copy construction or copy assignment, and using
"is trivially copy constructible" can in theory even give the wrong result if
the copy constructor is trivial but the move constructor is not.

PiperOrigin-RevId: 520488816
Change-Id: I6da4d57f3ce23b03044e0bf9aa70a14b51651fa3

PiperOrigin-RevId: 520197681
Change-Id: I96d0253b61bb683bf30060a9b4c19e2c9dce629b

PiperOrigin-RevId: 519939158
Change-Id: I9b049fa55167ed4064f3909887eec7bc52601677

It currently gives the wrong result for types with a user-provided destructor:

    struct S {
      ~S();
    };

    static_assert(!__is_trivially_relocatable(S));

PiperOrigin-RevId: 519855600
Change-Id: I5f0659ad0831974805a5ed4b615e3b6250d23154

There's no reason to require the type to be trivially
copy-constructible/assignable in order to avoid running destructors—those
traits have nothing to do with destruction.

PiperOrigin-RevId: 519822201
Change-Id: I2ed7bbb53f0c1a512017115ff29fb27a24c6b11a

absl int128: avoid shifting signed integer by a number of bits greater than or equal to the precision of the operand

PiperOrigin-RevId: 519808237
Change-Id: I9123b167b606d609b8f3924d6f4fd298fa866a90

PiperOrigin-RevId: 519786979
Change-Id: Ic5b69c1ac37b47db01d613edca5504e6611657b5

We can do a lot better than always saying "no" on platforms without the
__is_trivially_relocatable builtin. This will allow using this type trait from
the move constructors of InlinedVector in a future CL, without needing to open
code the fallback logic.

PiperOrigin-RevId: 519281125
Change-Id: I0d55f019331966f58074850d6f77c7eab49f2c53

This type trait had no precise definition, and indeed not even any documentation
at all. Giving the ill-defined concept a name was harmful, because it obscured
several places where the concept was used too conservatively, or even flat-out
incorrectly.

This CL has no behavior change: it simply expands IsMemcpyOk to the same
conditions it previously had. It leaves TODOs for each place where this was too
conservative or incorrect.

PiperOrigin-RevId: 519278325
Change-Id: I25bc89f299f6e40b5c3bce7370ed90f33a95612f

Clarify that the trait is conservative: it's safe to act on if it's true, but
false doesn't necessarily mean anything. Of course this is the only reasonable
way to use it, but I think it's helpful to be explicit, especially because
currently this trait *always* returns false on some platforms even for a type
like int.

PiperOrigin-RevId: 519272294
Change-Id: Ic63a48dcf18efc0756046b3d6f51d11cbb46a469

std::unique_ptr is trivially relocatable, but not trivially destructible. This
will be important coverage to ensure correctness of upcoming commit(s) that
expand the use of memcpy to more trivially relocatable types.
PiperOrigin-RevId: 519270234
Change-Id: I8e584a405633dac89bf1f67eab8145971d2ddab2

PiperOrigin-RevId: 519200954
Change-Id: I349023cacab0ac4cbefb8505efd29a5eda1e9067

In preparation for changing its definition in an upcoming commit.

PiperOrigin-RevId: 519141790
Change-Id: I49b608a575ad41e2f29d82489c1c09eec8c4d7e5

PiperOrigin-RevId: 519090305
Change-Id: Ic97a36da33e1e0681765a913f3c54c3d818eebdc

https://devblogs.microsoft.com/cppblog/msvc-cpp20-and-the-std-cpp20-switch/#c20-no_unique_address
MSVC disables [[no_unique_address]] by default because of ABI
compatibility. Since Abseil does not claim ABI compatibility in
mixed-mode builds, we can offer it unconditionally.

Fixes #1418

PiperOrigin-RevId: 518894036
Change-Id: If7653e65703b335783f11d296de7e32fc35d4fc6

PiperOrigin-RevId: 518850294
Change-Id: I3e9dcce5de2ae878d0992f05c0f39ccaf10a1ac5

PiperOrigin-RevId: 518835147
Change-Id: I86d8a49563cb5f74461a57e2b6dceac539749c86

This implementation may at some point become the default on some
platforms.  Currently not all platforms have widespread support for
both real absolute timeouts or real relative timeouts (here "real"
means without converting to the other timeout type which is the only
one supported by the underlying APIs). In this case we can defer to
their standard library to implement correct support.

This is not currently the default on any platform

Note: The size of WaiterState had to increase to fit the new implementation
PiperOrigin-RevId: 518266646
Change-Id: I7f246646a960d6e1b155f9de0bf2f681c5d3d245

PiperOrigin-RevId: 518198160
Change-Id: Ib4fe53e0b0b371472b6b9473aeb84779953b6a38

Instead of being only able to test the platform Waiter implementation,
this allows us to be able to test all Waiter implementations that
build on a specific platform.

A unittest is added that tests all implementations that work for the
platform, and allows us to check that the expected one is being used
by printing the name of the selected implementation.

PiperOrigin-RevId: 518072415
Change-Id: Ie9e6fcd9d8283b4038e6f4e68a304d2adcc04b19