The implementation is fine and has the proper increment/decrement
operators defined, but the tests were wrong:
- a typo (`T` instead of `std::atomic_ref<T>`) when ensuring that increment/decrement
operators are not defined in the primary template and specialization for floating point
types, and
- the specialization for pointer types was miscategorized.
This PR fixes the erroneous internal capacity evaluation in
`vector<bool>`, which caused a subsequent SIGSEGV error when calling
`flip()` on `vector<bool>`. By fixing the internal capacity evaluation,
the SIGSEGV is automatically resolved.
According to
[[template.bitset.general]](https://eel.is/c++draft/template.bitset.general),
`std::bitset` is supposed to have only
one (public) member typedef, `reference`. However, libc++'s
implementation of `std::bitset` offers more that that. Specifically, it
offers a public typedef `const_reference` and two private typedefs
`size_type` and `difference_type`. These non-standard member typedefs,
despite being private, can cause potential ambiguities in name lookup in
user-defined classes, as demonstrated in issue #121618.
Fixing the public member typedef `const_reference` is straightforward:
we can simply replace it with an `__ugly_name` such as
`__const_reference`. However, fixing the private member typedefs
`size_type` and `difference_type` is not so straightforward as they are
required by the `__bit_iterator` class and the corresponding algorithms
optimized for `__bit_iterator`s (e.g., `ranges::fill`).
This PR fixes the member typedef `const_reference` by using uglified
name for it. Further work will be undertaken to address `size_type` and
`difference_type`.
Follows up #80706, #111127, and #112843,
The `std::error_code`/`std::error_category` functionality is designed to
support multiple error domains. On Unix, both system calls and libc
functions return the same error codes, and thus, libc++ today treats
`generic_category()` and `system_category()` as being equivalent.
However, on Windows, libc functions return `errno.h` error codes in the
`errno` global, but system calls return the very different `winerror.h`
error codes via `GetLastError()`.
As such, there is a need to map the winerror.h error codes into generic
errno codes. In libc++, however, the system_error facility does not
implement this mapping; instead the mapping is hidden inside libc++,
used directly by the std::filesystem implementation.
That has a few problems:
1. For std::filesystem APIs, the concrete windows error number is lost,
before users can see it. The intent of the distinction between
std::error_code and std::error_condition is that the error_code return
has the original (potentially more detailed) error code.
2. User-written code which calls Windows system APIs requires this same
mapping, so it also can also return error_code objects that other
(cross-platform) code can understand.
After this commit, an `error_code` with `generic_category()` is used to
report an error from `errno`, and, on Windows only, an `error_code` with
`system_category()` is used to report an error from `GetLastError()`. On
Unix, system_category remains identity-mapped to generic_category, but
is never used by libc++ itself.
The windows error code mapping is moved into system_error, so that
conversion of an `error_code` to `error_condition` correctly translates
the `system_category()` code into a `generic_category()` code, when
appropriate.
This allows code like:
`error_code(GetLastError(), system_category()) == errc::invalid_argument`
to work as expected -- as it does with MSVC STL.
(Continued from old phabricator review [D151493](https://reviews.llvm.org/D151493))
Adapted from libcxx/test/std/atomics/atomics.types.generic/atomics.types.float/exchange.pass.cpp
as we did for testing other functionalities. Spotted that lapse in coverage when working on #121414.
This optimizes `std::filesystem::copy_file` to use the `copy_file_range`
syscall (Linux and FreeBSD) when available. It allows for reflinks on
filesystems such as btrfs, zfs and xfs, and server-side copy for network
filesystems such as NFS.
This patch implements the forwarding to frozen C++03 headers as
discussed in
https://discourse.llvm.org/t/rfc-freezing-c-03-headers-in-libc. In the
RFC, we initially proposed selecting the right headers from the Clang
driver, however consensus seemed to steer towards handling this in the
library itself. This patch implements that direction.
At a high level, the changes basically amount to making each public
header look like this:
```
// inside <vector>
#ifdef _LIBCPP_CXX03_LANG
# include <__cxx03/vector>
#else
// normal <vector> content
#endif
```
In most cases, public headers are simple umbrella headers so there isn't
much code in the #else branch. In other cases, the #else branch contains
the actual implementation of the header.
This PR enhances the test coverage for std::vector::assign by adding new
tests for several important test cases that were previously missing, as
shown in the following table:
| test cases | forward_iterator | input_iterator |
|-----------------------------------|------------------|----------------|
| new_size > capacity() | Yes | Yes |
| size() < new_size <= capacity() | No | No |
| new_size <= size() | No | No |
Similarly, no tests have previously covered `assign(InputIterator, InputIterator)`
and `assign(size_type, const value_type&)` for `vector<bool>`.
With this patch applied, all missing tests are covered.
This commit reverts c3276a96d9 and 1901da32, which added a test to
ensure that type traits are derived from integral_constant. While that
is a fine test to add, the commit didn't go through a PR and as a result
it looks like some of our CI has been broken by it.
This should be an uncontroversial change, but let's re-land it via a PR
to get our usual CI coverage.
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`.
