This PR fixes the shared_ptr control block layout test that was recently updated in #76756.
When aligned allocation/deallocation is not available, part of the test doesn't work.
This reverts commit 78f9a8b82d772ff04a12ef95f2c9d31ee8f3e409.
This caused the LLDB test `TestDataFormatterGenericOptional.py` to fail, and we need
a bit more time to look into it.
This is regression test for #90292.
Allocator used in test is very similar to test_allocator.
However, reproducer requires size_type of the string
to be 64bit, but test_allocator uses 32bit.
32bit size_type makes `sizeof(string::__long)` to be 16,
but the alignment issue fixed with #90292 is only triggered
with default `sizeof(string::__long)` which is 24.
Fixes#92128.
---------
Co-authored-by: Louis Dionne <ldionne.2@gmail.com>
This removes the need for macOS nodes in Buildkite. It also moves to the
proper way of testing backdeployment, which is to actually run on the
target OS itself, instead of using packaged dylibs from previous OS
versions and trying to emulate backdeployment with DYLD_LIBRARY_PATH.
As a drive-by change, also fix a few back-deployment annotations that
were incorrect and add support for minor versions in the Lit feature
determining availability from the target triple.
This is a re-application of bc6bd3bc1e9 which was reverted in
f11abac6524 because it broke the Clang pre-commit CI.
Original commit message:
This patch rewrites the modulemap to have fewer top-level modules.
Previously, our modulemap had one top level module for each header in
the library, including private headers. This had the well-known problem
of making compilation times terrible, in addition to being somewhat
against the design principles of Clang modules.
This patch provides almost an order of magnitude compilation time
improvement when building modularized code (certainly subject to
variations). For example, including <ccomplex> without a module cache
went from 22.4 seconds to 1.6 seconds, a 14x improvement.
To achieve this, one might be tempted to simply put all the headers in a
single top-level module. Unfortunately, this doesn't work because libc++
provides C compatibility headers (e.g. stdlib.h) which create cycles
when the C Standard Library headers are modularized too. This is
especially tricky since base systems are usually not modularized: as far
as I know, only Xcode 16 beta contains a modularized SDK that makes this
issue visible. To understand it, imagine we have the following setup:
// in libc++'s include/c++/v1/module.modulemap
module std {
header stddef.h
header stdlib.h
}
// in the C library's include/module.modulemap
module clib {
header stddef.h
header stdlib.h
}
Now, imagine that the C library's <stdlib.h> includes <stddef.h>,
perhaps as an implementation detail. When building the `std` module,
libc++'s <stdlib.h> header does `#include_next <stdlib.h>` to get the C
library's <stdlib.h>, so libc++ depends on the `clib` module.
However, remember that the C library's <stdlib.h> header includes
<stddef.h> as an implementation detail. Since the header search paths
for libc++ are (and must be) before the search paths for the C library,
the C library ends up including libc++'s <stddef.h>, which means it
depends on the `std` module. That's a cycle.
To solve this issue, this patch creates one top-level module for each C
compatibility header. The rest of the libc++ headers are located in a
single top-level `std` module, with two main exceptions. First, the
module containing configuration headers (e.g. <__config>) has its own
top-level module too, because those headers are included by the C
compatibility headers.
Second, we create a top-level std_core module that contains several
dependency-free utilities used (directly or indirectly) from the __math
subdirectory. This is needed because __math pulls in a bunch of stuff,
and __math is used from the C compatibility header <math.h>.
As a direct benefit of this change, we don't need to generate an
artificial __std_clang_module header anymore to provide a monolithic
`std` module, since our modulemap does it naturally by construction.
A next step after this change would be to look into whether math.h
really needs to include the contents of __math, and if so, whether
libc++'s math.h truly needs to include the C library's math.h header.
Removing either dependency would break this annoying cycle.
Thanks to Eric Fiselier for pointing out this approach during a recent
meeting. This wasn't viable before some recent refactoring, but wrapping
everything (except the C headers) in a large module is by far the
simplest and the most effective way of doing this.
Fixes#86193
Previous PR #107344 fixed move constructor of `test_allocator` but
dropped test coverage for move construction in some cases. This PR
attempts to restore the test coverage.
Thanks @Quuxplusone for reminding.
Instead of changing the cast sequence to implicit conversion in
_`voidify`_, I think it is better to totally remove `__voidify` and use
`static_cast` to `void*`, which has equivalent effects.
Test coverage for const iterators are removed.
Now most affected algorithms are underconstrained, for which I submitted
[LWG3888](https://cplusplus.github.io/LWG/issue3888). I'm not sure
whether we should speculatively implement it at this moment, and thus
haven't added any `*.verify.cpp`.
In some control block types and `optional`, the stored objects are
changed to have cv-unqualified type.
Fixes#105119.
This is what we started doing in libc++ and it straightens up a lot of
things that only happened to work before, notably the presence of
relative rpaths in dylibs when running from the build tree.
This unlocks the ability to link against a just-built dylib but run
against another version of the dylib (for example the system-provided
one), which is necessary for proper backdeployment testing.
This patch adds a lot of code duplication between the libc++ and
libc++abi testing setups. However, there is already a large amount of
duplication and the only real way to get rid of it is to merge libc++abi
into libc++. In a way, this patch is a step in that direction because it
closes the gap between the two libraries' testing setup.
This allows catching OOB accesses inside `unique_ptr<T[]>` when the size
of the allocation is known. The size of the allocation can be known when
the unique_ptr has been created with make_unique & friends or when the
type necessitates an array cookie before the allocation.
This is a re-aplpication of 45a09d181 which had been reverted in
f11abac6 due to unrelated CI failures.
This reverts 3 commits:
45a09d1811d5d6597385ef02ecf2d4b7320c37c5
24bc3244d4e221f4e6740f45e2bf15a1441a3076
bc6bd3bc1e99c7ec9e22dff23b4f4373fa02cae3
The GitHub pre-merge CI has been broken since this PR went in. This
change reverts it to see if I can get the pre-merge CI working again.
Add `[[nodiscard]]` attribute to `std::prev` and `std::next`. Those are
potential pitfalls for users who might think they mutate the iterator.
Fixes#109452
This allows catching OOB accesses inside `unique_ptr<T[]>` when the size
of the allocation is known. The size of the allocation can be known when
the unique_ptr has been created with make_unique & friends or when the
type necessitates an array cookie before the allocation.
This patch rewrites the modulemap to have fewer top-level modules.
Previously, our modulemap had one top level module for each header in
the library, including private headers. This had the well-known problem
of making compilation times terrible, in addition to being somewhat
against the design principles of Clang modules.
This patch provides almost an order of magnitude compilation time
improvement when building modularized code (certainly subject to
variations). For example, including <ccomplex> without a module cache
went from 22.4 seconds to 1.6 seconds, a 14x improvement.
To achieve this, one might be tempted to simply put all the headers in a
single top-level module. Unfortunately, this doesn't work because libc++
provides C compatibility headers (e.g. stdlib.h) which create cycles
when the C Standard Library headers are modularized too. This is
especially tricky since base systems are usually not modularized: as far
as I know, only Xcode 16 beta contains a modularized SDK that makes this
issue visible. To understand it, imagine we have the following setup:
// in libc++'s include/c++/v1/module.modulemap
module std {
header stddef.h
header stdlib.h
}
// in the C library's include/module.modulemap
module clib {
header stddef.h
header stdlib.h
}
Now, imagine that the C library's <stdlib.h> includes <stddef.h>,
perhaps as an implementation detail. When building the `std` module,
libc++'s <stdlib.h> header does `#include_next <stdlib.h>` to get the C
library's <stdlib.h>, so libc++ depends on the `clib` module.
However, remember that the C library's <stdlib.h> header includes
<stddef.h> as an implementation detail. Since the header search paths
for libc++ are (and must be) before the search paths for the C library,
the C library ends up including libc++'s <stddef.h>, which means it
depends on the `std` module. That's a cycle.
To solve this issue, this patch creates one top-level module for each C
compatibility header. The rest of the libc++ headers are located in a
single top-level `std` module, with two main exceptions. First, the
module containing configuration headers (e.g. <__config>) has its own
top-level module too, because those headers are included by the C
compatibility headers.
Second, we create a top-level std_core module that contains several
dependency-free utilities used (directly or indirectly) from the __math
subdirectory. This is needed because __math pulls in a bunch of stuff,
and __math is used from the C compatibility header <math.h>.
As a direct benefit of this change, we don't need to generate an
artificial __std_clang_module header anymore to provide a monolithic
`std` module, since our modulemap does it naturally by construction.
A next step after this change would be to look into whether math.h
really needs to include the contents of __math, and if so, whether
libc++'s math.h truly needs to include the C library's math.h header.
Removing either dependency would break this annoying cycle.
Thanks to Eric Fiselier for pointing out this approach during a recent
meeting. This wasn't viable before some recent refactoring, but wrapping
everything (except the C headers) in a large module is by far the
simplest and the most effective way of doing this.
Fixes#86193
The CI has been a complete mess for the past week, and the only thing
preventing it from being back is the Clang tidy checks. Disable them (as
a total hack) to get CI back.
This extension is motivated by Android's use of libc++, where
<stdatomic.h> has redirected to <atomic> for many years, long before it
was standardized in C++23.
When libc++'s stdatomic.h is included in C translation units, delegate
to the next stdatomic.h, which could come from Clang or libc.
We were incorrectly computing whether a FTM has been implemented.
Instead of checking whether any version of the FTM is implemented for
the current Standard, we need to make sure that the correct version of
the FTM has been implemented.
As a drive-by fix, also correctly close the file that we load JSON from,
which was forgotten.
The paper was implemented by commit b0386a515b60c
(https://reviews.llvm.org/D46845) in LLVM 7.0. But it would be nice to
have test coverage for desired properties of `insert_return_type`.
Closes#99944
This patch adds a large number of missing includes in the libc++ headers
and the test suite. Those were found as part of the effort to move
towards a mostly monolithic top-level std module.
Works towards P0619R4 / #99985.
The use of `std::get_temporary_buffer` and `std::return_temporary_buffer`
are replaced with `unique_ptr`-based RAII buffer holder.
Escape hatches:
- `_LIBCPP_ENABLE_CXX20_REMOVED_TEMPORARY_BUFFER` restores
`std::get_temporary_buffer` and `std::return_temporary_buffer`.
Drive-by changes:
- In `<syncstream>`, states that `get_temporary_buffer` is now removed,
because `<syncstream>` is added in C++20.
This significantly simplifies the code, improves compile times and
improves the object layout of types using `__compressed_pair` in the
unstable ABI. The only downside is that this is extremely ABI sensitive
and pedantically breaks the ABI for empty final types, since the address
of the subobject may change. The ABI of the whole object should not be
affected.
Fixes#91266Fixes#93069
It appears that ::link is also declared as another kind of symbol
in <unistd.h>, which we seem to get transitively when we start using
a single top-level module. Instead of declaring these names as global
extern variables, use function parameters to achieve the same thing.
## Why
Following up on https://github.com/llvm/llvm-project/pull/105946, this
patch provides the floating point overloads for `std::signbit` as
defined by
[P0533R9](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2021/p0533r9.pdf).
## What
* Test and add overloads for cv-unqualified floating point types
* Remove constrained overload as it is not needed anymore
* Make use of `template<class = void>` as the universal C runtime (UCRT)
needed for Clang-Cl comes with overloads for all cv-unqualified floating
point types (float, double, long double) for `std::signbit()` by itself
[in the
WinSDK](e012b29924/generation/WinSDK/RecompiledIdlHeaders/ucrt/corecrt_math.h (L309-L322)).
In a certain way, this can be seen as a deviation from the C standard.
We need to work around it as the compilation would otherwise error out
due to duplicated definitions.
The poisoned_hash_helper header was relying on an implicit forward
declaration of std::hash located in <type_traits>. When we improve the
modularization of the library, that causes issues, in addition to being
a fundamentally non-portable assumption in the test suite.
It turns out that the reason for relying on a forward declaration is to
be able to test that std::hash is *not* provided if we don't include any
header that provides it. But testing that is actually both non-portable
and not really useful.
Indeed, what harm does it make if additional headers provide std::hash
specializations? That would certainly be conforming -- the Standard
never requires an implementation to avoid providing a declaration when a
given header is included, instead it mandates what *must* be provided
for sure. In that spirit, it would be conforming for e.g. `<cstddef>` to
define the hash specializations if that was our desire. I also don't
read https://wg21.link/P0513R0 as going against that statement. Hence,
this patch just removes that test which doesn't carry its weight.
Fixes#56938
We waited before supporting std::jthread fully because we wanted to
investigate other implementation strategies (in particular one involving
std::mutex). Since then, we did some benchmarking and decided that we
wouldn't be moving forward with std::mutex. Hence, there is no real
reason to punt on making std::jthread & friends non-experimental.
They were originally implemented in d42db7e083ee0 but reverted later in
a2f3c63282330be0.
This PR implement both LWG issues again, guarding the removed functions
with `_LIBCPP_STD_VER <= 14`, because they should be treated as patches
for P0302R1 which was adopted for C++17.
Fixes#103598Fixes#103755
The resolution of LWG2593 didn't require the standard library
implementation to change. It merely strengthened requirements on
user-defined allocator types and allowed the implementation to make
stronger assumptions. The status is tentatively set to Nothing To Do.
However, `test_allocator` in libc++'s test suit needs to be fixed to
conform to the strengthened requirements.
Closes#100220.
When we introduced the machinery for transitive includes validation, at
some point we stopped including the full set of transitive includes in
the CSV files and instead only tracked the set of public headers
included *directly* by a top-level header.
The reason for doing that was so that the CSV files containing
"transitive" includes could be used to draw the dependency graph of
libc++ headers. However, the downside was that it made the contents of
the CSV files much harder to interpret.
In particular, many changes that modify the CSV files do not in fact
modify the effective set of transitive includes, which is confusing.
This patch goes back to storing the full set of transitive includes in
the CSV files and removes the ability to graph the libc++ includes
directly from those CSV files, which we never actually used.
This patch adds caching of file attributes during directory iteration
on Windows. This improves the performance when working with files being
iterated on in a directory.
Add a few missing includes, remove two unnecessary ones and use
__cstddef/size_t.h instead of <cstddef> in a few places. This is a
collection of miscellaneous findings that collectively unblock other
modularization patches.
## Why
Since 18th of August, the floating point comparison builtin
``__builtin_signbit`` is available in Clang as constant expression
(https://github.com/llvm/llvm-project/pull/94118).
## What
* Implement `constexpr` for `std::signbit()` as defined by
[P0533R9](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2021/p0533r9.pdf)
(new C++23 feature)
* Restrict execution of tests to tip-of-trunk Clang as builtin is not
yet available (note that builtin is available in GCC)
Many headers include `<cstddef>` just for size_t, and pulling in
additional content (e.g. the traits used for std::byte) is unnecessary.
To solve this problem, this patch splits up `<cstddef>` into
subcomponents so that headers can include only the parts that they
actually require.
This has the added benefit of making the modules build a lot stricter
with respect to IWYU, and also providing a canonical location where we
define `std::size_t` and friends (which were previously defined in
multiple headers like `<cstddef>` and `<ctime>`).
After this patch, there's still many places in the codebase where we
include `<cstddef>` when `<__cstddef/size_t.h>` would be sufficient.
This patch focuses on removing `<cstddef>` includes from __type_traits
to make these headers non-circular with `<cstddef>`. Additional
refactorings can be tackled separately.
Some modules are leaf modules in the sense that they are not used by any
other part of the headers. These leaf modules are easy to consolidate
since there is no risk to create a cycle. As a result of regrouping
these modules, several missing includes were found and fixed in this
patch.
That dependency was added recently when we made improvements to
std::hypot, but that resulted in `__math` depending on `__algorithm`,
which is a very heavyweight module. This patch uses `__math::fmax`
instead.
We split up all the headers into top-level modules when we broke up
cycles with the C compatibility headers. However, this resulted in a
large number of small modules, which is awkward and clearly against the
philosophy of Clang modules. This was necessary to make things work.
This patch regroups a few headers from two leaf modules: stop_token and
pstl. It should be pretty uncontroversial that grouping these headers
into a single module doesn't introduce any cyclic dependency, yet it's a
first step towards reducing the number of top-level modules we have in
our modulemap.
