[libc++] Re-add transitive includes that had been removed since LLVM 14

This commit re-adds transitive includes that had been removed by
4cd04d1687f1, c36870c8e79c, a83f4b9cda57, 1458458b558d, 2e2f3

[libc++] Re-add transitive includes that had been removed since LLVM 14

This commit re-adds transitive includes that had been removed by
4cd04d1687f1, c36870c8e79c, a83f4b9cda57, 1458458b558d, 2e2f3158c604,
and 489637e66dd3. This should cover almost all the includes that had
been removed since LLVM 14 and that would contribute to breaking user
code when releasing LLVM 15.

It is possible to disable the inclusion of these headers by defining
_LIBCPP_REMOVE_TRANSITIVE_INCLUDES. The intent is that vendors will
enable that macro and start fixing downstream issues immediately. We
can then remove the macro (and the transitive includes) by default in
a future release. That way, we will break users only once by removing
transitive includes in bulk instead of doing it bit by bit a every
release, which is more disruptive for users.

Note 1: The set of headers to re-add was found by re-generating the
transitive include test on a checkout of release/14.x, which
provided the list of all transitive includes we used to provide.

Note 2: Several includes of <vector>, <optional>, <array> and <unordered_map>
have been added in this commit. These transitive inclusions were
added when we implemented boyer_moore_searcher in <functional>.

Note 3: This is a best effort patch to try and resolve downstream breakage
caused since branching LLVM 14. I wasn't able to perfectly mirror
transitive includes in LLVM 14 for a few headers, so I added a
release note explaining it. To summarize, adding boyer_moore_searcher
created a bunch of circular dependencies, so we have to break
backwards compatibility in a few cases.

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

show more ...

[libc++] Mark standard-mandated includes as such

Reviewed By: ldionne, Mordante, #libc, saugustine

Spies: saugustine, MaskRay, arichardson, mstorsjo, jloser, libcxx-commits, arphaman

Differential

[libc++] Mark standard-mandated includes as such

Reviewed By: ldionne, Mordante, #libc, saugustine

Spies: saugustine, MaskRay, arichardson, mstorsjo, jloser, libcxx-commits, arphaman

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

show more ...

[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++] Explicitly reject `uniform_int_distribution<bool>` and `<char>`.

`uniform_int_distribution<T>` is UB unless `T` is one of the non-character,
non-boolean integer types (`short` or larger). H

[libc++] Explicitly reject `uniform_int_distribution<bool>` and `<char>`.

`uniform_int_distribution<T>` is UB unless `T` is one of the non-character,
non-boolean integer types (`short` or larger). However, libc++ has never
enforced this. D114129 accidentally made `uniform_int_distribution<bool>`
into an error. Make it now *intentionally* an error; and likewise for the
character types and all user-defined class and enum types; but permit
`__[u]int128_t` to continue working.

Apply the same static_assert to all the integer distributions.

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

show more ...

[libc++] Granularize algorithm includes

Reviewed By: Mordante, ldionne, Quuxplusone, #libc, #libc_abi

Spies: #libc_vendors, libcxx-commits, miyuki

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

[libc++] Granularize algorithm includes

Reviewed By: Mordante, ldionne, Quuxplusone, #libc, #libc_abi

Spies: #libc_vendors, libcxx-commits, miyuki

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

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++] 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++] Extract __clamp_to_integral to its own header

In addition to being more consistent with our approach for helpers, this
solves an actual issue where <cmath> was using numeric_limits but neve

[libc++] Extract __clamp_to_integral to its own header

In addition to being more consistent with our approach for helpers, this
solves an actual issue where <cmath> was using numeric_limits but never
including the <limits> header directly. In a normal setup, this is not
an issue because the <math.h> header included by <cmath> does include
<limits>. However, I did stumble upon some code where that didn't work,
most likely because they were placing their own <math.h> header in front
of ours. I didn't bother investigating further.

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

show more ...

[libc++] Granularize the <random> header. NFCI.

Actually there's one functional change here, which is that users can
no longer depend on <random> to include all of C++20 <concepts>. That
inclusion i

[libc++] Granularize the <random> header. NFCI.

Actually there's one functional change here, which is that users can
no longer depend on <random> to include all of C++20 <concepts>. That
inclusion is so new that we believe nobody should be depending on it
yet, even in the presence of Hyrum's Law. We keep the includes of <vector>,
<algorithm>, etc., so as not to break pre-C++20 Hyrum's Law users.

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

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++] 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

[libc++] Remove "pass by const value" in <random>. NFCI.

[libcxx] Move all algorithms into their own headers

This is a fairly mechanical change, it just moves each algorithm into
its own header. This is intended to be a NFC.

This commit re-applies 7ed7d4

[libcxx] Move all algorithms into their own headers

This is a fairly mechanical change, it just moves each algorithm into
its own header. This is intended to be a NFC.

This commit re-applies 7ed7d4ccb899, which was reverted in 692d7166f771
because the Modules build got broken. The modules build has now been
fixed, so we're re-committing this.

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

Attribution note
----------------
I'm only committing this. This commit is a mix of D103583, D103330 and
D104171 authored by:

Co-authored-by: Christopher Di Bella <[email protected]>
Co-authored-by: zoecarver <[email protected]>

show more ...

[libc++] Alphabetize and include-what-you-use. NFCI.

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

[libc++] Remove more unnecessary _VSTD:: from type names. NFCI.

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

[libc++] s/_VSTD::is_unsigned/is_unsigned/ in <random>. NFCI.

[libc++] NFC: Normalize `#endif //` comment indentation

[libcxx] cleans up __cpp_concepts mess

libc++ was previously a bit confused by what the value of __cpp_concepts
should be. Also replaces `__floating_point` with `floating_point` now
that it exists.

[libcxx] cleans up __cpp_concepts mess

libc++ was previously a bit confused by what the value of __cpp_concepts
should be. Also replaces `__floating_point` with `floating_point` now
that it exists.

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

show more ...

[libcxx] adds concept `std::uniform_random_bit_generator`

Implements parts of:
- P0898R3 Standard Library Concepts
- P1754 Rename concepts to standard_case for C++20, while we still can

Dif

[libcxx] adds concept `std::uniform_random_bit_generator`

Implements parts of:
- P0898R3 Standard Library Concepts
- P1754 Rename concepts to standard_case for C++20, while we still can

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

show more ...

[libc++] [P0935] [C++20] Eradicating unnecessarily explicit default constructors from the standard library.

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0935r0.html

Reviewed By: ldionne

[libc++] [P0935] [C++20] Eradicating unnecessarily explicit default constructors from the standard library.

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0935r0.html

Reviewed By: ldionne, #libc

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

show more ...

[libcxx] Apply msvcrt specific exception for lgamma() to mingw configurations, too

This fixes linking code that uses some bits of the <random> header
on mingw targets.

Differential Revision: https:

[libcxx] Apply msvcrt specific exception for lgamma() to mingw configurations, too

This fixes linking code that uses some bits of the <random> header
on mingw targets.

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

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 ...

[libc++] Change requirements on linear_congruential_engine.

This patch changes how linear_congruential_engine picks its randomization
algorithm. It adds two restrictions, `_OverflowOK` and `_Schrage

[libc++] Change requirements on linear_congruential_engine.

This patch changes how linear_congruential_engine picks its randomization
algorithm. It adds two restrictions, `_OverflowOK` and `_SchrageOK`.
`_OverflowOK` means that m is a power of two so using the classic
`(a * x + c) % m` will create a meaningless overflow. The second checks
that Schrage's algorithm will produce results that are in bounds of min
and max. This patch fixes https://llvm.org/PR27839.

Differential Revision: D65041

show more ...

[libc++] Reduce dependencies on <iostream> from <random>

We included <istream> and <ostream> from <random>, but really it is
sufficient to include <iosfwd> if we make sure we access ios_base
members

[libc++] Reduce dependencies on <iostream> from <random>

We included <istream> and <ostream> from <random>, but really it is
sufficient to include <iosfwd> if we make sure we access ios_base
members through a dependent type. This allows us to break a hard
dependency of <random> on locales.

show more ...

[libc++] Allow building libc++ on platforms without a random device

Some platforms, like several embedded platforms, do not provide a source
of randomness through a random device. This commit makes

[libc++] Allow building libc++ on platforms without a random device

Some platforms, like several embedded platforms, do not provide a source
of randomness through a random device. This commit makes it possible to
build and test libc++ for such platforms, i.e. without std::random_device.

Surprisingly, the only functionality that doesn't work on such platforms
is std::random_device itself -- everything else in <random> still works,
one just has to find alternative ways to seed the PRNGs.

show more ...