Implement P2401 which adds a `noexcept` specification to
`std::exchange`. Treated as a defect fix which is the motivation for
applying this change to all standards mode rather than just C++23 or
later as the paper suggests.

Reviewed By: Quuxplusone, Mordante, #libc

Differential Revision: https://reviews.llvm.org/D111481

Implement P2251 which requires `span` and `basic_string_view` to be
trivially copyable. They already are - this just adds tests to bind that
behavior.

Reviewed By: ldionne, Quuxplusone, Mordante, #libc

Differential Revision: https://reviews.llvm.org/D111197

Differential Revision: https://reviews.llvm.org/D110735

Replace `TEST_NOEXCEPT_FALSE` directly with `noexcept(false)` in
optional hash test which is only run in C++17 or later.
`TEST_NOEXCEPT_FALSE` is only useful in C++03 context where `noexcept`
isn't supported by clang. `TEST_NOEXCEPT_FALSE` now only has one remaining use
in `hash_unique_ptr.pass.cpp`.

`{ind.move.subsumption.compile.pass.cpp}` was accidentally commited in
https://reviews.llvm.org/D102639. Per the conversation on Discord in

Implement parts of P1614, including three-way comparison for tuples, and expand testing.

Reviewed By: ldionne, Mordante, #libc

Differential Revision: https://reviews.llvm.org/D108250

Implement https://wg21.link/p1394 which allows span to be constructible
from any contiguous forwarding-range that has a compatible element type.

Fixes https://bugs.llvm.org/show_bug.cgi?id=51443

Reviewed By: ldionne, Quuxplusone, #libc

Differential Revision: https://reviews.llvm.org/D110503

While looking at the review comments in D103765 there was an oddity in
the tests for the following functions:
- atomic_fetch_add
- atomic_fetch_add_explicit
- atomic_fetch_sub
- atomic_fetch_sub_explicit

Libc++ allows usage of
`atomic_fetch_add<int>(atomic<int*>*, atomic<int*>::difference_type);`
MSVC and GCC reject this code: https://godbolt.org/z/9d8WzohbE

This makes the atomic `fetch(add|sub).*` Standard conforming and removes the non-conforming extensions.

Fixes PR47908

Reviewed By: ldionne, #libc

Differential Revision: https://reviews.llvm.org/D103983

Replace `&__rhs` with `_VSTD::addressof(__rhs)` to guard against ADL hijacking
of `operator&` in `operator=`. Thanks to @CaseyCarter for bringing it to our
attention.

Similar issues with hijacking `operator&` still exist, they will be
addressed separately.

Reviewed By: #libc, Quuxplusone, ldionne

Differential Revision: https://reviews.llvm.org/D110852

Implements the formatter for Boolean types.
[format.formatter.spec]/2.3
For each charT, for each cv-unqualified arithmetic type ArithmeticT other
than char, wchar_t, char8_t, char16_t, or char32_t, a specialization
```
  template<> struct formatter<ArithmeticT, charT>;
```
This removes the stub implemented in D96664.

Implements parts of:
- P0645 Text Formatting
- P1652 Printf corner cases in std::format

Completes:
- P1868 width: clarifying units of width and precision in std::format

Reviewed By: #libc, ldionne

Differential Revision: https://reviews.llvm.org/D103670

Implements the formatter for all fundamental integer types.
[format.formatter.spec]/2.1
The specializations
```
  template<> struct formatter<char, char>;
  template<> struct formatter<char, wchar_t>;
  template<> struct formatter<wchar_t, wchar_t>;
```
This removes the stub implemented in D96664.

Implements parts of:
- P0645 Text Formatting

Reviewed By: #libc, ldionne

Differential Revision: https://reviews.llvm.org/D103466

Implements the formatter for all fundamental integer types
(except `char`, `wchar_t`, and `bool`).
[format.formatter.spec]/2.3
For each charT, for each cv-unqualified arithmetic type ArithmeticT other
than char, wchar_t, char8_t, char16_t, or char32_t, a specialization
```
  template<> struct formatter<ArithmeticT, charT>;
```
This removes the stub implemented in D96664.

As an extension it adds partial support for 128-bit integer types.

Implements parts of:
- P0645 Text Formatting
- P1652 Printf corner cases in std::format

Completes:
- LWG-3248 #b, #B, #o, #x, and #X presentation types misformat negative numbers

Reviewed By: #libc, ldionne, vitaut

Differential Revision: https://reviews.llvm.org/D103433

Implements the formatter for all string types.
[format.formatter.spec]/2.2
For each charT, the string type specializations
```
  template<> struct formatter<charT*, charT>;
  template<> struct formatter<const charT*, charT>;
  template<size_t N> struct formatter<const charT[N], charT>;
  template<class traits, class Allocator>
    struct formatter<basic_string<charT, traits, Allocator>, charT>;
  template<class traits>
    struct formatter<basic_string_view<charT, traits>, charT>;
```
This removes the stub implemented in D96664.

Implements parts of:
- P0645 Text Formatting
- P1868 width: clarifying units of width and precision in std::format

Reviewed By: #libc, ldionne, vitaut

Differential Revision: https://reviews.llvm.org/D103425

The unique (ha!) thing about this range type is that it's move-only.
Its contiguity is unsurprising (most of our test ranges are contiguous).
Discussed in D111231 but committed separately for clarity.

If you have a `begin() const` member, you don't need a `begin()` member
unless you want it to do something different (e.g. have a different return
type). So in general, //view// types don't need `begin()` non-const members.

Also, static_assert some things about the types in "types.h", so that we
don't accidentally break those properties under refactoring.

Differential Revision: https://reviews.llvm.org/D111231

Implement P1391 (https://wg21.link/p1391) which allows
`std::string_view` to be constructible from any contiguous range of
characters.

Note that a different paper (http://wg21.link/P1989) handles the generic
range constructor for `std::string_view`.

Reviewed By: ldionne, Quuxplusone, Mordante, #libc

Differential Revision: https://reviews.llvm.org/D110718

Some tests repeat the definition of `DELETE_FUNCTION` macro locally.
However, it's not even requred to guard against in the C++03 case since
Clang supports `= delete;` in C++03 mode. A warning is issued but
`libc++` tests run with `-Wno-c++11-extensions`, so this isn't an issue.
Since we don't support other compilers in C++03 mode, `= delete;` is
always available for use. As such, inline all calls of `DELETE_FUNCTION`
to use `= delete;`.

Reviewed By: ldionne, #libc

Differential Revision: https://reviews.llvm.org/D111148

Test file defines `LIBCPP11_STATIC_ASSERT` but it never uses it now. It
always uses `static_assert` unconditionally. So, remove the unused
macro.

This was missed in ec574f5d. TIME_UTC
is a define that goes along with timespec_get. The testcase that it is
moved to is only run for >= C++17, so the surrounding ifdef guard
can be dropped.

Differential Revision: https://reviews.llvm.org/D110988

The existing tests for transform_view::iterator weren't quite right,
and can be simplified now that we have more of C++20 available to us.
Having done that, let's use the same pattern for iota_view::iterator
as well.

Differential Revision: https://reviews.llvm.org/D110774

Discussed in D110794.

Even if these comments have a benefit in .h files (for editors that
care about language but can't be configured to treat .h as C++ code),
they certainly have no benefit for files with the .cpp extension.

Discussed in D110794.

This reverts commit 9892d164, which
causes clang test failures in libcxx tests.

Differential Revision: https://reviews.llvm.org/D110433

Vendors take libc++ and ship it in various ways. Some vendors might
ship it differently from what upstream LLVM does, i.e. the install
location might be different, some ABI properties might differ, etc.

In the past few years, I've come across several instances where
having a place to test some of these properties would have been
incredibly useful. I also just got bitten by the lack of tests
of that kind, so I'm adding some now.

The tests added by this commit for Apple platforms have numerous
TODOs that capture discrepancies between the upstream LLVM CMake
and the slightly-modified build we perform internally to produce
Apple's system libc++. In the future, the goal would be to upstream
all those differences so that it's possible to build a faithful
Apple system libc++ with the upstream LLVM sources only.

But this isn't only useful for Apple - this lays out the path for
any vendor being able to add their own checks (either upstream or
downstream) to libc++.

Differential Revision: https://reviews.llvm.org/D110736

Some of these were previously half-implemented in "ordering.h";
now they're all implemented, and tested.
Note that `constexpr` functions are implicitly `inline`, so the
standard wording omits `inline` on these; but Louis and I agree
that that's surprising and it's better to be explicit about it.

Differential Revision: https://reviews.llvm.org/D110515

This is consistent with what we've been doing forever.

Instead of using a base class to store the members and the optional
size, use [[no_unique_address]] to achieve the same thing without
needing a base class.

Also, as a fly-by:
- Change subrange from struct to class (per the standard)
- Improve the diagnostic for when one doesn't provide a size to the ctor of a sized subrange
- Replace this->member by just member since it's not in a dependent base anymore

This change would be an ABI break due to [[no_unique_address]], but we
haven't shipped ranges anywhere yet, so this shouldn't affect anyone.

Differential Revision: https://reviews.llvm.org/D110370

Before this patch, we had features named 'libc++', 'libstdc++' and
'msvc' to describe the three implementations that use our test suite.
This patch renames them to 'stdlib=libc++', 'stdlib=libstdc++', etc
to avoid confusion between MSVC's STL and the MSVC compiler (or Clang
in MSVC mode).

Furthermore, this prepares the terrain for adding support for additional
"implementations" to the test suite. Basically, I'd like to be able to
treat Apple's libc++ differently from LLVM's libc++ for the purpose of
testing, because those effectively behave in different ways in some aspects.

In reaction to the issues raised by Richard in https://llvm.org/D109066,
this commit does not apply P1951 as a DR in previous standard modes,
since it breaks valid code.

I do believe it should be applied as a DR, however ideally we'd get some
sort of statement from the Committee to this effect (and all implementations
would behave consistently). In the meantime, only implement P1951 starting
with C++23 -- we can always come back and apply it as a DR if that's what
the Committee says.

Differential Revision: https://reviews.llvm.org/D110347

Mostly, remove the global assumption that all ranges have size 8.
I should have called this out during the initial review.

Implements parts of P1614, including synth-three-way and three way comparison for std::pair.

Reviewed By: #libc, Quuxplusone, Mordante

Differential Revision: https://reviews.llvm.org/D107721

Instead of overloading `__to_address`, let's specialize `pointer_traits`.
Function overloads need to be in scope at the point where they're called,
whereas template specializations do not. (User code can provide pointer_traits
specializations to be used by already-included library code, so obviously
`__wrap_iter` can do the same.)

`pointer_traits<__wrap_iter<It>>` cannot provide `pointer_to`, because
you generally cannot create a `__wrap_iter` without also knowing the
identity of the container into which you're trying to create an iterator.
I believe this is OK; contiguous iterators are required to provide
`to_address` but *not* necessarily `pointer_to`.

Differential Revision: https://reviews.llvm.org/D110198

Several tests include `disable_missing_braces_warning.h` but do not need
to. Remove the include.

Inspired from discussion at https://reviews.llvm.org/D109668

Reviewed By: ldionne, #libc, Mordante

Differential Revision: https://reviews.llvm.org/D109711

LWG 2447 is marked as `Complete`, but there is no `static_assert` to
reject volatile types in `std::allocator`. See the discussion at
https://reviews.llvm.org/D108856.

Add `static_assert` in `std::allocator` to disallow volatile types. Since this
is an implementation choice, mark the binding test as `libc++` only.

Remove tests that use containers backed by `std::allocator` that test
the container when used with a volatile type.

Reviewed By: ldionne, #libc

Differential Revision: https://reviews.llvm.org/D109056

Two tests in span.cons/deduct.pass.cpp accidentally check whether the
iterator range from member begin and member end are equivalent to the
ones from free begin and free end. This is obviously true and not
intended. Correct the intent by comparing the size/data from the span
with the source input.

While in the neighborhood, add test for const int arr[N], remove extraneous
type aliases, unused <type_traits> header, and the
disable_missing_braces_warning.h include.

Reviewed By: Quuxplusone, ldionne, #libc

Differential Revision: https://reviews.llvm.org/D109668