Reformat Mutex-related files so that incremental formatting changes
don't distract during review of logical changes.
These files are subtle and any unnecessary diffs make reviews harder.

No changes besides running clang-format.

PiperOrigin-RevId: 541981737
Change-Id: I41cccb7a97158c78d17adaff6fe553c2c9c2b9ed

PiperOrigin-RevId: 541915097
Change-Id: I7ebfbafc36db38b59b30ab5b312cd7e22082a805

PiperOrigin-RevId: 541111597
Change-Id: I88165130e30e548a03d8d6173dadab33dc18b21e

PiperOrigin-RevId: 540928490
Change-Id: Idf022b28ce101a948be4efd5336888a66f5eacf9

Currently when we queue the first thread, we don't init its priority.
Subsequent queued threads init priority, but they compare it against
the first thread priority, which is uninit. Thus the order can be wrong.
It can lead to complete false starvation in some corner cases.

On Linux the default priority is 0, which matches the uninit value,
thus the problem is harder to spot on Linux (only possible if explicit
thread priorities are used). But on Darwin the default priority is 31,
thus the first thread falsely looks like lower priority than subsequently
queued threads. The added test exposes the problem on Darwin.

Always initialize the priority before queuing threads.

PiperOrigin-RevId: 540814133
Change-Id: I513ce1493a67afe77d3e92fb49000b046b42a9f2

Move the comment that relates to kMuDesig close to kMuDesig definition.
Currently it's placed in between unrelated flags.

NFC

PiperOrigin-RevId: 540792401
Change-Id: I5f6a928cd9e01664812b2a7c3d9eb087c0723d7f

which makes it give up in certain situations where the x86 handler works
fine

This change adopts x86's more sophisticated stack-bounds-checking
method for aarch64, and enables the HugeStack test to pass on aarch64.

PiperOrigin-RevId: 540655431
Change-Id: If7d816330327722bbe5c135abfa77fda5e7e452b

It no longer strictly writes to stderr, since Emscripten/WebAssembly now use _emscripten_err which might be replaced by something that is not the same as stderr by the host.

PiperOrigin-RevId: 540655336
Change-Id: Icc2a430a0db53a1282ef5558e9f3648db67e972c

PiperOrigin-RevId: 540586646
Change-Id: Iac1e133647fbaa5036ac9ef7322f9af5886c658e

This bypasses the need for filesystem APIs just for stderr access.

PiperOrigin-RevId: 540367155
Change-Id: Ib91dadac28cb5c8e571407b5dfa60c3e65539c95

PiperOrigin-RevId: 539960446
Change-Id: If2de8bf32ffeed849280f78f8ac0685e11e80f59

PiperOrigin-RevId: 539900072
Change-Id: I675386e3184f6f5ab70b851add970c91d1dde9c5

PiperOrigin-RevId: 539784770
Change-Id: Ie224afa04af023bbddc89b967e8c8440f9e8a887

implementation.

PiperOrigin-RevId: 539749773
Change-Id: Iec83431ffd360a077b153cea00427580ae287d1f

PiperOrigin-RevId: 539747818
Change-Id: Ia0ab0fdda0ffe9b23d83d55c899f301df20b1179

PiperOrigin-RevId: 539726003
Change-Id: Ie38f8d48a7b4c9d498fc1c4c4af6138048f80f68

This is a conservative change, in that it only contains bugfixes and allows new patterns that used to be compile errors.  There are other changes we would like to make (as reflected in the comments in char_formatting_test.cc), but we are being careful about the implications of such behavior changes.

The two implementation changes are:
* Apply integral promotions to enums before printing them, so they are always treated as integers (and not chars) by StrCat and StrFormat.
* Classify `unsigned char` and `signed char` as integer-like rather than char-like, so that `StrFormat("%v", v)` accepts those types as integers (consistent with `StrCat()`.)

The behavior changes are:
* StrCat() now accepts char-backed enums (rather than failing to compile).
* StrFormat("%v") now accepts `signed char` and `unsigned char` as integral (rather than failing to compile).
* StrFormat("%v") now correctly formats 8-bit enums as integers (rather than failing internally and emitting nothing).

Tested:
  Modified the char_formatting_test.cc case to reflect changes.
  Re-ran all other tests.
PiperOrigin-RevId: 539659674
Change-Id: Ief56335f5a57e4582af396d00eaa9e7b6be4ddc6

off_t is best for portability. Its size varies with the platform.
off64_t is non-standard, but is present in glibc and some BSDs.
It also matches the signature specified in the manual.
https://man7.org/linux/man-pages/man2/mmap.2.html

This is a re-spin of #1349, but correctly casts the type to the type
expected by the kernel for mmap2.
https://man7.org/linux/man-pages/man2/mmap2.2.html

Fixes #1473

PiperOrigin-RevId: 539656313
Change-Id: I7a30dd9d3eb6af03a99da0d93d721a86f6521b25

AppleClang seem to allocate two extra 64-bit words per each `new[]`.

A test should pass larger buffer to a placement `new[]`.

Fixes #1090

Introduce kHighRefcountMask which masks off flags and the LSb of the refcount value. In the cases where this mask is used, we don't need to check the LSb because we can assume the refcount is 1 when the rest of the masked RefcountAndFlags is empty, and the LSb doesn't matter if the masked value is not empty (either it's immortal or refcount > 1). This saves an instruction and a cycle (and + cmp -> tst) https://godbolt.org/z/Kz69eqfhq

PiperOrigin-RevId: 539151659
Change-Id: I2ec7d72918f052c4b0938edd746af9d5b3052c7e

PiperOrigin-RevId: 539145188
Change-Id: Ic8dc8112f77ca720a8871de57ee389f15693ab00

This fixes an endless loop in the absl Arm stack unwinder where encountering a
second signal return trampoline (as one has in nested signal frames), would restart
unwinding at the outermost signal, resulting in an endless loop.

This does not change any behavior in the non-nested signal case, so I believe
it is safe for any stack that hasn't encountered this bug already.

I would love to test this beyond the absl unwinding test cases and the
fingerprint_test included here, but I'm at a loss for other test cases.

PiperOrigin-RevId: 539113007
Change-Id: I10037f9fa77b45cc4db61f89b9c6380ec3529113

This is a simplification but not a behavior change; we used to choose %u for unsigned ints, but %u and %d generate the same output for these types.

PiperOrigin-RevId: 539104599
Change-Id: I9d7ff561b969a6287889f95063636d6b77a4a78b

PiperOrigin-RevId: 539104398
Change-Id: I6385662e0c5694d40c57887f983b16adc9eced14

This patch makes it use `memcpy` for performance and consistency with other overloads.

PiperOrigin-RevId: 539079130
Change-Id: I5aea9dd9b8a1ce708c787df7d6c9a75ae419c484

in NACL pthread_self() returns a pointer that isn't directly convertible to arithmetic type.

PiperOrigin-RevId: 539023020
Change-Id: I3745ec5565f3a99ccb1d9df12c27a80e57ca4755

PiperOrigin-RevId: 538778978
Change-Id: I0c04b09987eb4d97892825e3c994656d4e300f60

PiperOrigin-RevId: 538651091
Change-Id: Id1aa7ab287beb252f4826f70e26b7e3bfa80c462

PiperOrigin-RevId: 538534137
Change-Id: Ifb2e59c36ffce183d3c93081d9300201757f82d4

Fixes #1469

PiperOrigin-RevId: 538534014
Change-Id: Iab84f73c0a0665355b614e85c62f686dc54c8671

PiperOrigin-RevId: 538488164
Change-Id: I680dcbc2f27dca3beba416b3cd0a55943751cf4c

Update XML output to properly print special characters. Non printable characters are skipped in output. All the "whitespace-like" (including \t, \r, \n) characters printed as plain space ' '.

PiperOrigin-RevId: 538479923
Change-Id: I62dff39bb21f376d00a7b9480f8f1d31d7015e45

PiperOrigin-RevId: 538241594
Change-Id: Ie6f0d913bcf07dea2f33e47198ba952b3800d70e

This is only a workaround, working only with gcc/clang, while waiting
for a better long term fix not using std::aligned_storage, which is
tracked by b/260219225.

Add a unit test that captures the current behavior of formatting of char types and char-backed enum types through StrCat(), StrFormat("%v"), and Substitute().

This test allows us to modify the behavior in this space without introducing undesired changes elsewhere.

PiperOrigin-RevId: 537981963
Change-Id: Icda91b66efcc0dc8c263011b137e130a3db2dc19

PiperOrigin-RevId: 537825067
Change-Id: I3ce8712d5130068fb7d77b563eb502e2e9560810

PiperOrigin-RevId: 537400816
Change-Id: I06794a6b8b6a441e34121047024380190d42869a