The calls to std::construct_at might overwrite the previously set
__has_value_ flag in the case where the flag is overlapping with
the actual value or error being stored (since we use [[no_unique_address]]).
To fix this issue, this patch ensures that we initialize the
__has_value_ flag after we call std::construct_at.
Fixes#68552
(cherry picked from commit 134c91595568ea1335b22e559f20c1a488ea270e)
As explained in `__config`, we have an ABI tag that we use to ensure
that we don't run into ODR issues when mixing different versions of
libc++ in multiple TUs. However, the reasoning behind that extends not
only to different versions of libc++, but also to different
configurations of the same version of libc++. In fact, we've been aware
of this for a while but never really bothered to make the change because
ODR issues are often thought to be benign.
Well, it turns out that I just spent over an hour banging my head
against an issue that boils down to our lack of encoding of some ODR
properties in the ABI tag, so here's the patch we should have done a
long time ago.
For now, the ODR properties we encode in the ABI tag are:
- library version
- exceptions vs no-exceptions
- hardening mode
Those are all things that we support different values for on a per-TU
basis and they definitely affect ODR in a meaningful way. We can add
more properties later as we see fit.
(cherry picked from commit bc792a284362696c91599f9ab01f74eda4b9108f)
Specifically, the test std/input.output/string.streams/stringstream/stringstream.members/gcount.pass.cpp
allocates a std::string with INT_MAX-1 elements, and then writes this to
a std::stringstream. On Linux, running this test consumes around 5.0 GB
of memory; on Windows, it ends up using up to 6.8 GB of memory.
This limits whether such tests can run on e.g. GitHub Actions runners,
where the free runners are limited to 8 GB of memory.
This is somewhat similar to, but still notably different, from the
existing test parameter long_tests.
(cherry picked from commit 122064a6303eb9c06e0af231f5a4ce145d9a2e67)
The helper function `__pair_like_explicit_wknd` is only SFINAE-ed with
`tuple_size<remove_cvref_t<_PairLike>>::value == 2`, but its function
body assumes `std::get` being valid.
Fixes#65620
(cherry picked from commit 054f9c55c6b4520d3feb8b4354b9b942026b5124)
This patch effectively maintains the status quo, making sure that the
safe mode keeps working the same way as before. Hardening will target
the next major release, allowing it to go through RFC and for the
implementation to stabilize and mature.
Differential Revision: https://reviews.llvm.org/D159171
PowerPC on linux currently don't have support for lowering long double for
frexp(). Removing the tests until implementation is provided.
Reviewed By: #libc, amyk, Mordante
Differential Revision: https://reviews.llvm.org/D158547
(cherry picked from commit 5adac8bebcf26841c1d87227c5043af83a9ef94b)
Prevent these tests from failing on some platforms (the number of
constexpr steps increased by https://reviews.llvm.org/D154860).
(cherry picked from commit 91876eab93a9f0ef29a339ed99bdb1c8ed1e85c6)
- Make a test for an internal concept libc++-only;
- Make sure that `size` and `capacity` in a test container return the
same type on all platforms.
(cherry picked from commit 8b9a98661b780a5b50d1d6a1f822d25e0c454382)
Use header_information to generate the __std_clang_module header. Instead of using lit_header_restrictions like the manually written header did, make a new header_include_requirements to codify what can be included rather than what can be fully tested.
Reviewed By: Mordante, #libc
Differential Revision: https://reviews.llvm.org/D157364
# Conflicts:
# libcxx/utils/libcxx/header_information.py
I need to use header_information.py in a generator script that isn't for tests in an upcoming change. Move it up a level so that it's in utils/libcxx instead of utils/libcxx/tests.
Differential Revision: https://reviews.llvm.org/D157639
# Conflicts:
# libcxx/test/libcxx/system_reserved_names.gen.py
`print` functions require `FILE` and `stdout` to be available and cause
compilation errors on platforms that don't support the file system.
Differential Revision: https://reviews.llvm.org/D156585
(cherry picked from commit 1cf970db4e5499f6b38d9c6644935a78d758802c)
It was using the stride calculation of layout_right.
Reviewed By: philnik
Differential Revision: https://reviews.llvm.org/D157065
(cherry picked from commit 0f4d7d81c9d08512a3871596fa2a14b737233c80)
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
(cherry picked from commit a800485a2deda0807cb9dc212b7d42ac916055fd)
Fixes uglification in mdspan deduction guides, which CI
did not test for until recently. The CI modification
and mdspan testing overlapped, so mdspan landed with green
CI, and the CI modification landed too.
Make most assertions in mdspan and its helper classes
trigger during a hardened build in order to catch
out of bounds access errors.
Also moves all mdspan assertions tests from libcxx/test/std
to libcxx/test/libcxx.
Differential Revision: https://reviews.llvm.org/156181
This implements P0009 std::mdspan ((https://wg21.link/p0009)),
a multidimensional span with customization points for
layouts and data access.
Co-authored-by: Damien L-G <dalg24@gmail.com>
Differential Revision: https://reviews.llvm.org/154367
Implements parts of
- P2093R14 Formatted output
- P2539R4 Should the output of std::print to a terminal be
synchronized with the underlying stream?
Depends on D150044
Reviewed By: #libc, ldionne
Differential Revision: https://reviews.llvm.org/D155262
The hardened mode is intended to only include security-critical,
relatively low-overhead checks that are intended to be usable in
production. By default, assertions are excluded from this mode.
Differential Revision: https://reviews.llvm.org/D155866
The Apple.cmake cache wasn't set up properly, so we wouldn't enable
the libdispatch backend by default on Apple platforms. This patch
fixes the issue and adds a test.
We also need to make various drive-by fixes:
- Drop the usage of std::vector in libdispatch.h to avoid changing
the transitive includes only on Apple platforms.
- Fix includes
- Use __construct at since construct_at is unavailable in C++17
- Get rid of the (unused) __get_memory_resource function since that
adds a back-deployment requirement and we don't use it right now.
- Fix bugs in the chunking logic around boundary conditions.
Differential Revision: https://reviews.llvm.org/D155649
The headers that include_next compiler and OS headers need to be in different top level modules in order to avoid module cycles. e.g. libc++'s stdlib.h will #include_next stdlib.h from the compiler and then the C library. Either of those are likely to include stddef.h, which will come back up to the libc++ module map and create a module cycle. Putting stdlib.h and stddef.h (and the rest of the C standard library headers) in top level modules resolves this by letting the order go cxx_stdlib_h -> os_stdlib_h -> cxx_stddef_h -> os_stddef_h.
All of those headers' dependencies then need to be moved into top level modules themselves to avoid module cycles between the new top level level cstd modules. This starts to get complicated, as the libc++ C headers, by standard, have to include many of the C++ headers, which include the private detail headers, which are intertwined. e.g. some `__algorithm` headers include `__memory` headers and vice versa.
Make top level modules for all of the libc++ headers to easily guarantee that the modules aren't cyclic.
Add enough module exports to fix `check-cxx` and `run-buildbot generic-modules`.
`__stop_token/intrusive_shared_ptr.h` uses `__atomic/atomic.h` but has no include path to it. Add that include.
`math.h` absorbs `bits/atomic_wide_counter.h` on some platforms that don't have modules, work around that by including `math.h` in `__threading_support`.
<mutex> doesn't actually require threads, there are a few pieces like once_flag that work without threads. Remove the requirement from its module.
AIX is no longer able to support modular builds.
Reviewed By: ldionne, #libc
Differential Revision: https://reviews.llvm.org/D144322
Next to sanitizer-aarch64-linux-bootstrap-msan it appears asan and
hwasan are broken on aarch64. To unbreak the CI disable these two
sanitizer checks too.
The breakage was introduced by D150044.
This patch is part of our efforts to support container annotations with (almost) every allocator.
Annotating std::deque with default allocator is implemented in D132092.
Support in ASan API exests since rG1c5ad6d2c01294a0decde43a88e9c27d7437d157.
The motivation for a research and those changes was a bug, found by Trail of Bits, in a real code where an out-of-bounds read could happen as two strings were compared via a `std::equals` function that took `iter1_begin`, `iter1_end`, `iter2_begin` iterators (with a custom comparison function).
When object `iter1` was longer than `iter2`, read out-of-bounds on `iter2` could happen. Container sanitization would detect it.
If you have any questions, please email:
- advenam.tacet@trailofbits.com
- disconnect3d@trailofbits.com
Reviewed By: #libc, ldionne
Differential Revision: https://reviews.llvm.org/D146815
As @ldionne pointed out to me in a newer revision, there is a //REQUIRE comment in both files edited by this patch that prevents the test to run on some platforms where it should actually run.
Reviewed By: #libc, ldionne
Differential Revision: https://reviews.llvm.org/D155755
When LLVM is built under MSVC and libcxx ABI is set to 2, the
'copy_move.pass' test will unexpectedly pass. This patch mitigate
this issue by setting this test will only expecting FAIL when libcxx
ABI version is set to 1.
This is a re-land of be9f55f4fff47badcdca17be5bcc0a4a15894739
Differential Revision: https://reviews.llvm.org/D155760
Fixes: https://github.com/llvm/llvm-project/issues/63442
This reverts commit be9f55f4fff47badcdca17be5bcc0a4a15894739.
The commit was both not approved by the libc++ review group, and also
the only change it contained was incorrect.
When LLVM is built under MSVC and libcxx ABI is set to 2, the
'copy_move.pass' test will unexpectedly pass. This patch mitigate this
issue by setting this test will only expecting FAIL when libcxx ABI
version is set to 1.
Differential Revision: https://reviews.llvm.org/D155760
Fixes: https://github.com/llvm/llvm-project/issues/63442
Adding assertions will aid users that have bugs or logic mistakes in
their code to receive error messages when debugging.
Differential Revision: https://reviews.llvm.org/D155399
These tests break with msan on the sanitizer-aarch64-linux-bootstrap-msan
builder. Note the x86_64 builder is not affected. To unbreak the CI
temporary disable the tests completely with msan.
The breakage was introduced by D150044.
The number of days should be rounded down, for both positive and
negative times since epoch. The original code truncated, which is
correct for positive values, but wrong for negative values.
Depends on D138826
Reviewed By: #libc, ldionne
Differential Revision: https://reviews.llvm.org/D154865
Improves both the compile-time and run-time errors.
At compile-time it does a bit more work to get more specific errors.
This could be done at run-time too, but that has a performance penalty.
Since it's expected most use-cases use format* instead of vformat* the
compile-time errors are more common.
For example when using
std::format_to("{:-c}", 42);
Before compile output would contain
std::__throw_format_error("The format-spec should consume the input or end with a '}'");
Now it contains
std::__throw_format_error("The format specifier does not allow the sign option");
Given a better indication the sign option is not allowed. Note the
output is still not user-friendly; C++ doesn't have good facilities to
generate nice messages from the library.
In general all messages have been reviewed and improved, using a more
consistent style and using less terms used in the standard. For example
format-spec -> format specifier
arg-id -> argument index
Reviewed By: #libc, ldionne
Differential Revision: https://reviews.llvm.org/D152624
After parsing a std-format-spec it's validated, depending on the type used some
format options are not allowed. This improves the error messages in the
exceptions thrown upon failure.
Depends on D155364
Reviewed By: #libc, ldionne
Differential Revision: https://reviews.llvm.org/D155366
Drive-by fix to make sure the __retarget_buffer works correctly whan
using a hint of 1. This was discovered in one of the new tests.
Drive-by fixes __retarget_buffer when initialized with size 1.
Implements parts of
- P2093R14 Formatted output
- P2539R4 Should the output of std::print to a terminal be
synchronized with the underlying stream?
Reviewed By: #libc, ldionne
Differential Revision: https://reviews.llvm.org/D150044
- add the `from_range_t` constructors and the related deduction guides;
- add the `insert_range`/`assign_range`/etc. member functions.
(Note: this patch is split from https://reviews.llvm.org/D142335)
Differential Revision: https://reviews.llvm.org/D149830
The operator++, operator++(int), operator--, and operator--(int) need to
change the month to a valid value. The wording is specified in terms of
operator+(const month& x, const months& y) noexcept;
which has the correct behavior. The aforementioned operators instead
used ++/-- on the internal value direction, resulting in incorrect
behaviour.
As a drive-by improve the unit tests:
- use the typical constexpr test method
- test whether the month is valid after the operations
- format the tests
Fixes: https://llvm.org/PR63912
Reviewed By: #libc, ldionne
Differential Revision: https://reviews.llvm.org/D155504
The empty.sh.cpp test never tested what it was intended to test, because
it did contain an unexpected RUN: command. This was discovered in
https://reviews.llvm.org/D154987 while trying to land an unrelated change.
Since there is no reliable way to test what I was trying to test from
the libc++ test suite, just remove the test.
The post-condition on the functions is that the buffer is not full.
This post-conditon is used as pre-condition of the push_back function.
When a copy, fill, of transform function exactly fit in the buffer this
post-condition was validated.
Reviewed By: #libc, ldionne
Differential Revision: https://reviews.llvm.org/D155397
Our threading support layer is currently a huge mess. There are too many
configurations with too many confusing names, and none of them are tested
in the usual CI. Here's a list of names related to these configurations:
LIBCXX_BUILD_EXTERNAL_THREAD_LIBRARY
_LIBCPP_BUILDING_THREAD_LIBRARY_EXTERNAL
LIBCXXABI_BUILD_EXTERNAL_THREAD_LIBRARY
_LIBCPP_HAS_THREAD_LIBRARY_EXTERNAL
LIBCXX_HAS_EXTERNAL_THREAD_API
_LIBCPP_HAS_THREAD_API_EXTERNAL
This patch cleans this up by removing the ability to build libc++ with
an "external" threading library for testing purposes, removing 4 out of
6 "names" above. That setting was meant to be used by libc++ developers,
but we don't use it in-tree and it's not part of our CI.
I know the ability to use an external threading API is used by some folks
out-of-tree, and this patch doesn't change that. This only changes the
way they will have to test their external threading support. After this
patch, the intent would be for them to set `-DLIBCXX_HAS_EXTERNAL_THREAD_API=ON`
when building the library, and to provide their usual `<__external_threading>`
header when they are testing the library. This can be done easily now
that we support custom lit configuration files in test suites.
The motivation for this patch is that our threading support layer is
basically unmaintainable -- anything beyond adding a new "backend" in
the slot designed for it requires incredible attention. The complexity
added by this setting just doesn't pull its weigh considering the
available alternatives.
Concretely, this will also allow future patches to clean up
`<__threading_support>` significantly.
Differential Revision: https://reviews.llvm.org/D154466
