[libc++] Ensure that all public C++ headers include <__assert>

This patch changes the requirement for getting the declaration of the
assertion handler from including <__assert> to including any publ

[libc++] Ensure that all public C++ headers include <__assert>

This patch changes the requirement for getting the declaration of the
assertion handler from including <__assert> to including any public
C++ header of the library. Note that C compatibility headers are
excluded because we don't implement all the C headers ourselves --
some of them are taken straight from the C library, like assert.h.

It also adds a generated test to check it. Furthermore, this new
generated test is designed in a way that will make it possible to
replace almost all the existing test-generation scripts with this
system in upcoming patches.

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

show more ...

[libc++] Normalize all our '#pragma GCC system_header', and regression-test.

Now we'll notice if a header forgets to include this magic phrase.

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

[libc++] Normalize all our '#pragma GCC system_header', and regression-test.

Now we'll notice if a header forgets to include this magic phrase.

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

show more ...

[libc++] [P1614] Implement the second half of [cmp.alg]: compare_{strong,weak,partial}_fallback.

The tests for these are just copy-pasted from the tests for std::{strong,weak,partial}_order,
and the

[libc++] [P1614] Implement the second half of [cmp.alg]: compare_{strong,weak,partial}_fallback.

The tests for these are just copy-pasted from the tests for std::{strong,weak,partial}_order,
and then I added an extra clause in each (test_2()) to test the stuff that's not just the same
as std::*_order.

This also includes the fix for https://wg21.link/LWG3465 (which falls naturally out of the
"you must write it three times" style, but I've added test cases for it also).

There is an action item here to go back and give good diagnostics for SFINAE failures
in these CPOs. I've filed this as https://github.com/llvm/llvm-project/issues/53456 .

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

show more ...

[libc++] Add the version header to all headers.

Some headers which require the version header depend on other headers to
provide it. Include the version header in all top-level headers to make
sure

[libc++] Add the version header to all headers.

Some headers which require the version header depend on other headers to
provide it. Include the version header in all top-level headers to make
sure a header cleanup can't remove the version header.

Note this doesn't add the version header to the c headers.

Reviewed By: #libc, Quuxplusone, ldionne

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

show more ...

[libc++] Add missing `#pragma GCC system_header` in a few headers. NFCI.

[libc++] [P1614] Implement [cmp.alg]'s std::{strong,weak,partial}_order.

This does not include `std::compare_*_fallback`; those are coming later.

There's still an open question of how to implement

[libc++] [P1614] Implement [cmp.alg]'s std::{strong,weak,partial}_order.

This does not include `std::compare_*_fallback`; those are coming later.

There's still an open question of how to implement std::strong_order
for `long double`, which has 80 value bits and 48 padding bits on x86-64,
and which is presumably *not* IEEE 754-compliant on PPC64 and so on.
So that part is left unimplemented.

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

show more ...

[runtimes][NFC] Remove filenames at the top of the license notice

We've stopped doing it in libc++ for a while now because these names
would end up rotting as we move things around and copy/paste st

[runtimes][NFC] Remove filenames at the top of the license notice

We've stopped doing it in libc++ for a while now because these names
would end up rotting as we move things around and copy/paste stuff.
This cleans up all the existing files so as to stop the spreading
as people copy-paste headers around.

show more ...

[libc++] Remove _LIBCPP_HAS_NO_SPACESHIP_OPERATOR

All supported compilers support spaceship in C++20 nowadays.

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

[libc++] [P1614] Implement std::compare_three_way.

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

[libc++] [compare] Named comparison functions, is_eq etc.

Some of these were previously half-implemented in "ordering.h";
now they're all implemented, and tested.
Note that `constexpr` functions are

[libc++] [compare] Named comparison functions, is_eq etc.

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

show more ...

[libc++][compare] Implement three_way_comparable[_with] concepts

Implementation of `three_way_comparable` and `three_way_comparable_with` concepts from <compare> header.

Please note that I have tem

[libc++][compare] Implement three_way_comparable[_with] concepts

Implementation of `three_way_comparable` and `three_way_comparable_with` concepts from <compare> header.

Please note that I have temporarily removed `<compare>` header from `<utility>` due to cyclic dependency that prevents using `<concepts>` header in `<compare>` one.

I tried to quickly resolve those issues including applying suggestions from @cjdb and dive deeper by myself but the problem seems more complicated that we thought initially.

I am in progress to prepare the patch with resolving this cyclic dependency between headers but for now I decided to put all that I have to the review to unblock people that depend on that functionality. At first glance the patch with resolving cyclic dependency is not so small (unless I find the way to make it smaller and cleaner) so I don't want to mix everything to one review.

Reviewed By: ldionne, cjdb, #libc, Quuxplusone

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

show more ...

[libc++][NFC] Remove unused include in <compare>.

`<type_traits>` was included in the first iteration of `<compare>` when
it was created as a monolithic header, then never removed. Removing it
now i

[libc++][NFC] Remove unused include in <compare>.

`<type_traits>` was included in the first iteration of `<compare>` when
it was created as a monolithic header, then never removed. Removing it
now is a beneficial no-op since it is not guaranteed by the standard
and is already included by all of its subheaders.

Reviewed By: cjdb, #libc, Quuxplusone

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

show more ...

[libc++] [P1614] Implement std::compare_three_way_result.

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

[libc++] Remove excess whitespace in synopsis comment. NFCI.

[libc++][modularisation] Split <compare> into internal headers.

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

[libc++] Fix a few warnings in system headers with GCC

This isn't fixing all of them, but at least it's making some progress.

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

[libcxx] modifies `_CmpUnspecifiedParam` ignore types outside its domain

D85051's honeypot solution was a bit too aggressive swallowed up the
comparison types, which made comparing objects of differ

[libcxx] modifies `_CmpUnspecifiedParam` ignore types outside its domain

D85051's honeypot solution was a bit too aggressive swallowed up the
comparison types, which made comparing objects of different ordering
types ambiguous.

Depends on D101707.

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

show more ...

[libcxx] makes comparison operators for `std::*_ordering` types hidden friends

The standard leaves it up to the implementation to decide whether or not
these operators are hidden friends. There are

[libcxx] makes comparison operators for `std::*_ordering` types hidden friends

The standard leaves it up to the implementation to decide whether or not
these operators are hidden friends. There are several (well-documented)
reasons to prefer hidden friends, as well as an argument for improved
readability.

Depends on D100342.

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

show more ...

[libcxx] removes operator!= and globally guards against no spaceship operator

* `operator!=` isn't in the spec
* `<compare>` is designed to work with `operator<=>` so it doesn't
really make sense

[libcxx] removes operator!= and globally guards against no spaceship operator

* `operator!=` isn't in the spec
* `<compare>` is designed to work with `operator<=>` so it doesn't
really make sense to have `operator<=>`-less friendly sections.

Depends on D100283.

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

show more ...

[libcxx] removes `weak_equality` and `strong_equality` from <compare>

`weak_equality` and `strong_equality` were removed before being
standardised, and need to be removed.

Also adjusts `common_comp

[libcxx] removes `weak_equality` and `strong_equality` from <compare>

`weak_equality` and `strong_equality` were removed before being
standardised, and need to be removed.

Also adjusts `common_comparison_category` since its test needed
adjusting due to the equality deletions.

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

show more ...

[libc++][NFC] Remove _VSTD:: when not needed.

Reviewed By: #libc, Quuxplusone

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

[libc++] Eliminate <compare>'s dependency on <array>.

This refactor is not only a good idea, but is in fact required by the standard,
in the sense that <array> is mandated to include <compare>.
So <

[libc++] Eliminate <compare>'s dependency on <array>.

This refactor is not only a good idea, but is in fact required by the standard,
in the sense that <array> is mandated to include <compare>.
So <compare> shouldn't have a circular dependency on <array>!

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

show more ...

[libc++] Consistently replace `std::` qualification with `_VSTD::` or nothing. NFCI.

I used a lot of `git grep` to find places where `std::` was being used
outside of comments and assert-messages. T

[libc++] Consistently replace `std::` qualification with `_VSTD::` or nothing. NFCI.

I used a lot of `git grep` to find places where `std::` was being used
outside of comments and assert-messages. There were three outcomes:

- Qualified function calls, e.g. `std::move` becomes `_VSTD::move`.
This is the most common case.

- Typenames that don't need qualification, e.g. `std::allocator` becomes `allocator`.
Leaving these as `_VSTD::allocator` would also be fine, but I decided
that removing the qualification is more consistent with existing practice.

- Names that specifically need un-versioned `std::` qualification,
or that I wasn't sure about. For example, I didn't touch any code in
<atomic>, <math.h>, <new>, or any ext/ or experimental/ headers;
and I didn't touch any instances of `std::type_info`.

In some deduction guides, we were accidentally using `class Alloc = typename std::allocator<T>`,
despite `std::allocator<T>`'s type-ness not being template-dependent.
Because `std::allocator` is a qualified name, this did parse as we intended;
but what we meant was simply `class Alloc = allocator<T>`.

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

show more ...

Fix test failures with trunk clang

- Make the consteval constructor for the zero type be noexcept
- Don't expect three-way comparison of 0 against a comparison category
to fail

Improve the representation of <compare>'s zero-only type.

* Use an empty struct instead of a member pointer to represent this
type, so that we don't actually pass a zero member pointer at runtime.

Improve the representation of <compare>'s zero-only type.

* Use an empty struct instead of a member pointer to represent this
type, so that we don't actually pass a zero member pointer at runtime.

* Mark the constructor as consteval to ensure that no code is emitted
for it whenever possible.

* Add a honeypot constructor to reject all non-int arguments, so that
the only argument that can arrive at the real constructor is the
literal 0.

This results in better generated code, and rejecting invalid comparisons
against nullptr, 0L, and so on, while also rejecting invalid comparisons
against (1-1) and similar that would be allowed if we required an
integer constant expression with value 0.

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

show more ...