This disentangles the code which previously had a mix of many #ifdefs, a
non-versioned namespace and a versioned namespace. It also makes it
clearer which parts of <new> are implemented on Windows by including <new.h>.
I'm exploring marking microsoft/STL's std::expected as [[nodiscard]],
which affects all functions returning std::expected, including its
own monadic member functions.
As usual, libc++'s test suite contains calls to these member functions
to make sure they compile, but it's discarding the returns. I'm adding
void casts to silence the [[nodiscard]] warnings without altering
what the test is covering.
This patch refactors the tests around aligned allocation and sized
deallocation to avoid relying on passing the -fsized-deallocation or
-faligned-allocation flags by default. Since both of these features are
enabled by default in >= C++14 mode, it now makes sense to make that
assumption in the test suite.
A notable exception is MinGW and some older compilers, where sized
deallocation is still not enabled by default. We treat that as a "bug"
in the test suite and we work around it by explicitly adding
-fsized-deallocation, but only under those configurations.
The existing exceptions tests for `vector<T>` have several issues: some
tests did not throw exceptions at all, making them not useful for
exception-safety testing, and some tests did not throw exceptions at the
intended points, failing to serve their expected purpose. This PR fixes
those tests for vector's constructors. Morever, this PR extracted common
classes and utilities into a separate header file, and renamed those
classes using more descriptive names.
The increasing_allocator<T> class, originally introduced to test shrink_to_fit()
for std::vector, std::vector<bool>, and std::basic_string, has duplicated
definitions across several test files. Given the potential utility of this
class for capacity-related tests in various sequence containers, this patch
refactors the definition of increasing_allocator<T> into a single, reusable
location.
This PR simplifies the implementation of std::vector's move constructor
with an alternative allocator by invoking __init_with_size() instead of
calling assign(), which ultimately calls __assign_with_size(). The
advantage of using __init_with_size() lies in its internal use of
an exception guard, which simplifies the code. Furthermore, from a
semantic standpoint, it is more intuitive for a constructor to call
an initialization function than an assignment function.
The Android clang-r536225 compiler identifies as Clang 19, but it is
based on commit fc57f88f007497a4ead0ec8607ac66e1847b02d6, which predates
the official LLVM 19.0.0 release.
Some tests need fixes:
* The sized delete tests fail because clang-r536225 leaves sized
deallocation off by default.
* std::array<T[0]> is true when this Android Clang version is used with
a trunk libc++, but we expect it to be false in the test. In practice,
Clang and libc++ usually come from the same commit on Android.
In particular, test everything with both a normal and a min_allocator,
add tests for a few corner cases and add tests with types that are
trivially relocatable. Also add tests that count the number of
assignments performed by vector::erase, since that is mandated by the
Standard.
This patch is a preparation for optimizing vector::erase.
After a recent Github Actions runner policy change [1], the version of
Xcode included in the macos-14 image went from Xcode 16 to Xcode 15,
breaking our build bots.
This moves the bots to the macos 15 (public preview) image, which
contains Xcode 16.
Also, adjust an UNSUPPORTED annotation that was incorrectly targeting
macos 13.7 when it should have been targeting a version of AppleClang.
[1]: https://github.com/actions/runner-images/issues/10703
Instead of going through the old locale entry points, define the base
localization API for BSD-like platforms (Apple and FreeBSD) from
scratch, using <xlocale.h> as a basis. This doesn't actually change how
that functionality is implemented, it only avoids going through a maze
to do so.
This clean new support is implemented in a separate __locale_dir/support
directory, which mirrors what we do for the threading support API.
Eventually, everything under __locale_dir/locale_base_api will go away.
rdar://131476632
Currently, libc++ incorrectly rejects heterogeneous comparison of
`unexpected`, because the `operator==` is only a hidden friend of
`unexpected<_Err>` but not of `unexpected<_Err2>`. We need to call the
`error()` member function on `__y`.
Fixes#115326
This patch introduces a new kind of bounded iterator that knows the size
of its valid range at compile-time, as in std::array. This allows computing
the end of the range from the start of the range and the size, which requires
storing only the start of the range in the iterator instead of both the start
and the size (or start and end). The iterator wrapper is otherwise identical
in design to the existing __bounded_iter.
Since this requires changing the type of the iterators returned by
std::array, this new bounded iterator is controlled by an ABI flag.
As a drive-by, centralize the tests for std::array::operator[] and add
missing tests for OOB operator[] on non-empty arrays.
Fixes#70864
We can define some of these aliases without having to include the system
<stddef.h> and there doesn't seem to be much of a reason we shouldn't do
it this way.
This PR fixes the `ThrowingT` class, which currently fails to raise
exceptions after a specified number of copy construction operations. The
class is intended to throw in a controlled manner based on a specified
counter value `throw_after`. However, its current implementation of the
copy constructor fails to achieve this goal.
The problem arises because the copy constructor does not initialize the
`throw_after_n_` member, leaving `throw_after_n_` to default to `nullptr`
as defined by the in-class initializer. As a result, its copy constructor
always checks against `nullptr`, causing an immediate exception rather
than throwing after the specified number `throw_after` of uses. The fix
is straightforward: simply initialize the `throw_after_n_` member in the
member initializer list.
This issue was previously uncovered because all exception tests for
`std::vector` in `exceptions.pass.cpp` used a `throw_after` value of 1,
which coincidentally aligned with the class's behavior.
Summary:
The GPU runs these tests using the files built from the `libc` project.
These will be placed in `include/<triple>` and `lib/<triple>`. We use
the `amdhsa-loader` and `nvptx-loader` tools, which are also provided by
`libc`. These launch a kernel called `_start` which calls `main` so we
can pretend like GPU programs are normal terminal applications.
We force serial exeuction here, because `llvm-lit` runs way too many
processes in parallel, which has a bad habit of making the GPU drivers
hang or run out of resources. This allows the compilation to be run in
parallel while the jobs themselves are serialized via a file lock.
In the future this can likely be refined to accept user specified
architectures, or better handle including the root directory by exposing
that instead of just `include/<triple>/c++/v1/`.
This currently fails ~1% of the tests on AMDGPU and ~3% of the tests on
NVPTX. This will hopefully be reduced further, and later patches can
XFAIL a lot of them once it's down to a reasonable number.
Future support will likely want to allow passing in a custom
architecture instead of simply relying on `-mcpu=native`.
Not all the code path has been exercised by the tests for
`flat_map::emplace_hint`
Adding more test coverage.
At the same time, adding more test cases for `flat_map::emplace`
This PR deprecates `<ccomplex>`, `<cstdbool>`, `<ctgmath>`, and
`<ciso646>` in C++17 and "removes" them in C++20 by special deprecation
warnings.
`<cstdalign>` is previously missing. This PR also tries to add them, and
then deprecates and "removes" `<cstdalign>`.
Papers:
- https://wg21.link/P0063R3
- https://wg21.link/P0619R4Closes#99985.
---------
Co-authored-by: Louis Dionne <ldionne.2@gmail.com>
Making it meet the requirements for allocator since C++11. Fixes
#113609.
This PR doesn't make it meet the C++03 allocator requirements, because
that would make the type too verbose and libc++ has backported many
C++11 features to the C++03 mode.
Drive-by: Removes the `TEST_CONSTEXPR_CXX14` on `allocate`/`dealocate`
which is never in effect (and causes IFNDR-ness before C++23), since
these functions modify the namespace-scoped variable `allocated_`.
Added exception guard to the `vector(n, x, a)` constructor to enhance
exception safety. This change ensures that the `vector(n, x, a)`
constructor is consistent with other constructors, such as `vector(n)`,
`vector(n, x)`, `vector(n, a)`, in terms of exception safety.
This implements a warning that's similar to what GCC does in that
context: both memcpy and memset require their first and second operand
to be trivially copyable, let's warn if that's not the case.
Around half of the tests are based on the tests Arthur O'Dwyer's
original implementation of std::flat_map, with modifications and
removals.
partially implement #105190
In C++20 mode, `__cpp_lib_optional` and `__cpp_lib_variant` should be
`202106L` due to DR P2231R1.
In C++26 mode, `__cpp_lib_variant` should be bumped to `202306L` due to
P2637R3.
- Clang 16/17 shouldn't get this bumping (as member `visit` requires
explicit object parameters), but it's very tricky to make the bumping
conditionally enabled. I _hope_ unconditionally bumping in C++26 will be
OK for LLVM 20 when the support for Clang 17 is dropped.
Related PRs:
- https://reviews.llvm.org/D102119
- #83335
- #76447
MSVC doesn't understand `-Wno-psabi`, which was introduced here by
@ldionne in #106077.
Using `ADDITIONAL_COMPILE_FLAGS(gcc-style-warnings)` (implemented by
#75317) avoids passing this to MSVC.
Implements std::from_chars for float and double.
The implementation uses LLVM-libc to do the real parsing. Since this is
the first time libc++
uses LLVM-libc there is a bit of additional infrastructure code. The
patch is based on the
[RFC] Project Hand In Hand (LLVM-libc/libc++ code sharing)
https://discourse.llvm.org/t/rfc-project-hand-in-hand-llvm-libc-libc-code-sharing/77701
`reverse_iterator` supports either c++20 `bidirectional_iterator` or
`Cpp17BidirectionalIterator `
http://eel.is/c++draft/reverse.iter.requirements
The current `reverse_iterator` uses `std::prev` in its `operator->`,
which only supports the `Cpp17BidirectionalIterator` properly.
If the underlying iterator is c++20 `bidirectional_iterator` but does
not satisfy the named requirement `Cpp17BidirectionalIterator`,
(examples are `zip_view::iterator`, `flat_map::iterator`), the current
`std::prev` silently compiles but does a no-op and returns the same
iterator back. So `reverse_iterator::operator->` will silently give a
wrong answer.
Even if we fix the behaviour of `std::prev`, at best, we could fail to
compile the code. But this is not ok, because we need to support this
kind of iterators in `reverse_iterator`.
The solution is simply to not use `std::prev`.
---------
Co-authored-by: Louis Dionne <ldionne.2@gmail.com>
Currently, libc++'s `bitset`, `forward_list`, and `list` have
non-conforming member typedef name `base`. The typedef is private, but
can cause ambiguity in name lookup.
Some other classes in libc++ that are either implementation details or
not precisely specified by the standard also have member typdef `base`.
I think this can still be conforming.
Follows up #80706 and #111127.
The changes are nearly pure simplifications, so I think it's OK to do
them together in the same PR.
Actual test coverages were already added in commit ad41d1e26b12
(https://reviews.llvm.org/D141216). Thanks to Casey Carter!
Fixes#104975
Towards #105200
