Reapply "[libc++][C++03] Copy the LLVM 19 headers (#108999)" (#112127)

This reverts commit 68c04b0ae62d8431d72d8b47fc13008002ee4387.

This disables the IWYU mapping that caused the failure, since

Reapply "[libc++][C++03] Copy the LLVM 19 headers (#108999)" (#112127)

This reverts commit 68c04b0ae62d8431d72d8b47fc13008002ee4387.

This disables the IWYU mapping that caused the failure, since
the headers aren't reachable for now.

This is the first part of the "Freezing C++03 headers" proposal
explained in
https://discourse.llvm.org/t/rfc-freezing-c-03-headers-in-libc/77319/58.

This patch mechanically copies the headers as of the LLVM 19.1 release
into a subdirectory of libc++ so that we can start using these headers
when building in C++03 mode. We are going to be backporting important
changes to that copy of the headers until the LLVM 21 release. After the
LLVM 21 release, only critical bugfixes will be fixed in the C++03 copy
of the headers.

This patch only performs a copy of the headers -- these headers are
still unused by the rest of the codebase.

show more ...

[libc++] Rewrite the transitive header checking machinery (#110554)

Since we don't generate a full dependency graph of headers, we can
greatly simplify the script that parses the result of --trace-

[libc++] Rewrite the transitive header checking machinery (#110554)

Since we don't generate a full dependency graph of headers, we can
greatly simplify the script that parses the result of --trace-includes.

At the same time, we also unify the mechanism for detecting whether a
header is a public/C compat/internal/etc header with the existing
mechanism in header_information.py.

As a drive-by this fixes the headers_in_modulemap.sh.py test which had
been disabled by mistake because it used its own way of determining
the list of libc++ headers. By consistently using header_information.py
to get that information, problems like this shouldn't happen anymore.

This should also unblock #110303, which was blocked because of
a brittle implementation of the transitive includes check which broke
when the repository was cloned at a path like /path/__something/more.

show more ...

[libc++][modules] Introduce a forward-declaration for std::byte (#107402)

We need a forward-declaration so that we can know about std::byte from
some type traits without having to include std::byte

[libc++][modules] Introduce a forward-declaration for std::byte (#107402)

We need a forward-declaration so that we can know about std::byte from
some type traits without having to include std::byte's definition, which
(circularly) depends back on type traits.

show more ...

[libc++] Split up ABI and platform configuration to their own headers (#90863)

This is a first step towards splitting up the <__config> header. The
<__config> header is large and rather disorganize

[libc++] Split up ABI and platform configuration to their own headers (#90863)

This is a first step towards splitting up the <__config> header. The
<__config> header is large and rather disorganized at this point,
leading to confusion and subtle mistakes. For example, we never noticed
that the string layout used on arm64 was only enabled for the Clang
compiler, as the setting being in the compiler == clang block was
probably never intentional.

The danger of splitting up the <__config> header is to implicitly use
undefined macros that should have been defined prior to their usage,
however this can be remediated with -Wundef and we've started moving
towards -Wundef enforceable macros.

show more ...

[libc++] Don't commit libcxx.imp (#89391)

We can instead generate it on-the-fly when we install the headers. This
reduces the amount of boilerplate we have to re-generate whenever we
add, remove o

[libc++] Don't commit libcxx.imp (#89391)

We can instead generate it on-the-fly when we install the headers. This
reduces the amount of boilerplate we have to re-generate whenever we
add, remove or relocate header files.

Fixes #88529

show more ...

[libc++][PSTL] Introduce cpu traits (#88134)

Currently, CPU backends in the PSTL are created by defining functions
in the __par_backend namespace. Then, the PSTL includes the CPU backend
that gets

[libc++][PSTL] Introduce cpu traits (#88134)

Currently, CPU backends in the PSTL are created by defining functions
in the __par_backend namespace. Then, the PSTL includes the CPU backend
that gets configured via CMake and gets those definitions.

This prevents CPU backends from easily co-existing and is a bit
confusing.
To solve this problem, this patch introduces the notion of __cpu_traits,
which is a cheap encapsulation of the basis operations required to
implement a CPU-based PSTL. Different backends can now define their own
tag and coexist, and the CPU-based PSTL will simply use __cpu_traits to
dispatch to the right implementation of e.g. __for_each.

Note that this patch doesn't change the actual implementation of the
backends in any way, it only modifies how that implementation is
accessed
to implement PSTL algorithms.

This patch is a step towards #88131.

show more ...

[libc++] Adds a global private constructor tag. (#87920)

This removes the similar tags used in the chrono tzdb implementation.

Fixes: https://github.com/llvm/llvm-project/issues/85432

[libc++] Rename __fwd/hash.h to __fwd/functional.h and add reference_wrapper (#81445)

We forward declare `reference_wrapper` in multiple places already. This
moves the declaration to the canonical

[libc++] Rename __fwd/hash.h to __fwd/functional.h and add reference_wrapper (#81445)

We forward declare `reference_wrapper` in multiple places already. This
moves the declaration to the canonical place and removes unnecessary
includes of `__functional/reference_wrapper.h`.

show more ...

[libc++] Map forward declaration headers for iostreams to <iosfwd> (#83327)

This seems more appropriate than mapping them to the headers that
contain actual definitions.

[libc++] Split the monolithic __threading_support header (#79654)

The <__threading_support> header is a huge beast and it's really
difficult to navigate. I find myself struggling to find what I wan

[libc++] Split the monolithic __threading_support header (#79654)

The <__threading_support> header is a huge beast and it's really
difficult to navigate. I find myself struggling to find what I want
every time I have to open it, and I've been considering splitting it up
for years for that reason.

This patch aims not to contain any functional change. The various
implementations of the threading base are simply moved to separate
headers and then the individual headers are simplified in mechanical
ways. For example, we used to have redundant declarations of all the
functions at the top of `__threading_support`, and those are removed
since they are not needed anymore. The various #ifdefs are also
simplified and removed when they become unnecessary.

Finally, this patch adds documentation for the API we expect from any
threading implementation.

show more ...

[libc++] Rewrite the IWYU generation (#78295)

This simplifies the IWYU generation script by treating everything as a
file, instead of dealing with directories and files separately.

This has the

[libc++] Rewrite the IWYU generation (#78295)

This simplifies the IWYU generation script by treating everything as a
file, instead of dealing with directories and files separately.

This has the downside that the `libcxx.imp` file is a lot larger than it
used to be, however we now have the flexibility of mapping files under
detail directories to different public headers. For example, this allows
us to map <__fwd/subrange.h> to <ranges> but <__fwd/pair.h> to
<utility>.

This patch also adds basic validation to ensure that we never map a
header to a public header that doesn't exist. We may still be missing
some mappings or we may be mapping to incorrect headers, but we won't be
mapping to headers that downright don't exist.

Fixes #63346

show more ...

[libc++][Modules] Recreate the top level `std` clang module

lldb needs the `std` clang module to make all of libc++ available in the debugger. Make a new header to include the rest of the public hea

[libc++][Modules] Recreate the top level `std` clang module

lldb needs the `std` clang module to make all of libc++ available in the debugger. Make a new header to include the rest of the public headers and use to build a `std` module that just re-exports the rest of libc++.

Reviewed By: Mordante, JDevlieghere, #libc

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

show more ...

[libc++] Remove the legacy debug mode.

See https://discourse.llvm.org/t/rfc-removing-the-legacy-debug-mode-from-libc/71026

Reviewed By: #libc, Mordante, ldionne

Differential Revision: https://revi

[libc++] Remove the legacy debug mode.

See https://discourse.llvm.org/t/rfc-removing-the-legacy-debug-mode-from-libc/71026

Reviewed By: #libc, Mordante, ldionne

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

show more ...

[NFC][Py Reformat] Reformat python files in libcxx/libcxxabi

This is an ongoing series of commits that are reformatting our
Python code.

Reformatting is done with `black`.

If you end up having pro

[NFC][Py Reformat] Reformat python files in libcxx/libcxxabi

This is an ongoing series of commits that are reformatting our
Python code.

Reformatting is done with `black`.

If you end up having problems merging this commit because you
have made changes to a python file, the best way to handle that
is to run git checkout --ours <yourfile> and then reformat it
with black.

If you run into any problems, post to discourse about it and
we will try to help.

RFC Thread below:

https://discourse.llvm.org/t/rfc-document-and-standardize-python-code-style

Reviewed By: #libc, kwk, Mordante

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

show more ...

[libc++] cuchar redeclares ::mbstate_t when it's in its own clang module

When cuchar is compiled independently on platforms that don't have <uchar.h>, it doesn't get a declaration of mbstate_t, and

[libc++] cuchar redeclares ::mbstate_t when it's in its own clang module

When cuchar is compiled independently on platforms that don't have <uchar.h>, it doesn't get a declaration of mbstate_t, and so makes an empty declaration for ::mbstate_t. That conflicts with the declarations in __mbstate_t.h and cwchar since both of those headers do get mbstate_t before making ::mbstate_t.

Change `__mbstate_t.h` to just get the underlying declaration for mbstate_t and not make a declaration for ::mbstate_t. Include __mbstate_t.h in uchar.h and wchar.h when their next headers aren't available so that at least mbstate_t gets defined.

Add __std_mbstate_t.h to declare ::mbstate_t for headers that need that when cuchar or cwchar aren't available (because either _LIBCPP_HAS_NO_WIDE_CHARACTERS or _LIBCPP_CXX03_LANG).

Reviewed By: ldionne, Mordante, #libc, philnik

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

show more ...

[libc++][PSTL] Copy the headers into libc++

We decided to integrate the PSTL into our own headers and only share the backend impletementations. This is a first step in that direction, specifically i

[libc++][PSTL] Copy the headers into libc++

We decided to integrate the PSTL into our own headers and only share the backend impletementations. This is a first step in that direction, specifically it copies the PSTL headers into the libc++ structure.

Reviewed By: ldionne, #libc

Spies: rodgert, mikhail.ramalho, jplehr, bcain, h-vetinari, Mordante, rarutyun, var-const, sstefan1, pcwang-thead, libcxx-commits, arichardson, mgrang, miyuki

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

show more ...

[libc++] Make bsd_locale_fallbacks.h modular and move it into __locale/locale_base_api/

This is a first step towards granularizing `<locale>`.

Reviewed By: ldionne, #libc

Spies: arichardson, libcx

[libc++] Make bsd_locale_fallbacks.h modular and move it into __locale/locale_base_api/

This is a first step towards granularizing `<locale>`.

Reviewed By: ldionne, #libc

Spies: arichardson, libcxx-commits, mikhail.ramalho

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

show more ...

[libc++] Rename __tuple_dir back to __tuple

This essentially reverts D139270

Reviewed By: #libc, EricWF

Spies: tahonermann, libcxx-commits, arichardson

Differential Revision: https://reviews.llvm

[libc++] Rename __tuple_dir back to __tuple

This essentially reverts D139270

Reviewed By: #libc, EricWF

Spies: tahonermann, libcxx-commits, arichardson

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

show more ...

[libcxx] Move the private header __std_stream into the src subdir

This header isn't used by any public header, so there shouldn't
be any need to install it or treat it as a heder.

Once it's part of

[libcxx] Move the private header __std_stream into the src subdir

This header isn't used by any public header, so there shouldn't
be any need to install it or treat it as a heder.

Once it's part of the src subdirectory, I guess one could consider
giving it a more traditional name too.

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

show more ...

[libc++] Rename __tuple to __tuple_dir to avoid file collision

Rename the `__tuple` directory in libc++ headers to `__tuple_dir`
to avoid file collision when installing. Historically, `__tuple` has

[libc++] Rename __tuple to __tuple_dir to avoid file collision

Rename the `__tuple` directory in libc++ headers to `__tuple_dir`
to avoid file collision when installing. Historically, `__tuple` has
been a file and it has been replaced by a directory
in 2d52c6bfae801b016dd3627b8c0e7c4a99405549. Replacing a regular file
with a directory (or more importantly, the other way around when
downgrading) is not universally supported. Since this is an internal
header, its actual name should not matter, so just rename it to avoid
problems.

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

show more ...

[libc++][NFC] Use if-else chain instead of match, which is a Python 3.10 construct

[libcxx] adds an include-what-you-use (IWYU) mapping file

This makes it possible for programmers to run IWYU and get more accurate
standard library inclusions. Prior to this commit, the following pr

[libcxx] adds an include-what-you-use (IWYU) mapping file

This makes it possible for programmers to run IWYU and get more accurate
standard library inclusions. Prior to this commit, the following program
would be transformed thusly:

```cpp
// Before
#include <algorithm>
#include <vector>

void f() {
auto v = std::vector{0, 1};
std::find(std::ranges::begin(v), std::ranges::end(v), 0);
}
```

```cpp
// After
#include <__algorithm/find.h>
#include <__ranges/access.h>
#include <vector>
...
```

There are two ways to fix this issue: to use [comment pragmas](https://github.com/include-what-you-use/include-what-you-use/blob/master/docs/IWYUPragmas.md)
on every private include, or to write a canonical [mapping file](https://github.com/include-what-you-use/include-what-you-use/blob/master/docs/IWYUMappings.md)
that provides the tool with a manual on how libc++ is laid out. Due to
the complexity of libc++, this commit opts for the latter, to maximise
correctness and minimise developer burden.

To mimimise developer updates to the file, it makes use of wildcards
that match everything within listed subdirectories. A script has also
been added to ensure that the mapping is always fresh in CI, and makes
the process a single step.

Finally, documentation has been added to inform users that IWYU is
supported, and what they need to do in order to leverage the mapping
file.

Closes #56937.

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

show more ...