According to the standard [vector.capacity]/5, std::vector<T>::reserve
shall throw an exception of type std::length_error when the requested
capacity exceeds max_size().
This behavior is not implemented correctly: the function 'reserve'
simply propagates the exception from allocator<T>::allocate. Before
D110846 that exception used to be of type std::length_error (which is
correct for vector<T>::reserve, but incorrect for
allocator<T>::allocate).
This patch fixes the issue and adds regression tests.
Reviewed By: Quuxplusone, ldionne, #libc
Differential Revision: https://reviews.llvm.org/D112068
std::vector<bool> rebinds the supplied allocator to construct objects
of type '__storage_type' rather than 'bool'. Allocators are allowed to
use explicit conversion constructors, so care must be taken when
performing conversions.
Reviewed By: ldionne, #libc
Differential Revision: https://reviews.llvm.org/D112150
The path functions in this patch are unimplemented (as per the TODO comment from upstream). To avoid running into a linker error (missing symbol), this patch raises a compile error by commenting out the functions, which is more user friendly.
Differential Revision: https://reviews.llvm.org/D111892
`weekday` has a static member function `__weekday_from_days` which is
not part of the mandated public interface of `weeekday` according to the
standard. Since it is only used internally in the constructors of
`weekday`, let's make it private.
Reviewed By: ldionne, Mordante, #libc
Differential Revision: https://reviews.llvm.org/D112072
Currently the member functions std::allocator<T>::allocate,
std::experimental::pmr::polymorphic_allocator::allocate and
std::resource_adaptor<T>::do_allocate throw an exception of type
std::length_error when the requested size exceeds the maximum size.
According to the C++ standard ([allocator.members]/4,
[mem.poly.allocator.mem]/1), std::allocator<T>::allocate and
std::pmr::polymorphic_allocator::allocate must throw a
std::bad_array_new_length exception in this case.
The patch fixes the issue with std::allocator<T>::allocate and changes
the type the exception thrown by
std::experimental::pmr::resource_adaptor<T>::do_allocate to
std::bad_array_new_length as well for consistency.
The patch resolves LWG 3237, LWG 3038 and LWG 3190.
Reviewed By: ldionne, #libc, Quuxplusone
Differential Revision: https://reviews.llvm.org/D110846
Implement LWG3480 which enables `directory_iterator` and
`recursive_directory_iterator` to be both a `borrowed_range` and a
`view`.
Reviewed By: ldionne, #libc
Differential Revision: https://reviews.llvm.org/D111644
Mark LWG3274 as complete. The feature test macro `__cpp_lib_span` was added in
`6d2599e4f776d0cd88438cb82a00c4fc25cc3f67`.
https://wg21.link/p1024 mentions marking `span:::empty()` with
`[[nodiscard]]` which is not done yet. So, do that and add tests.
Reviewed By: ldionne, Quuxplusone, Mordante, #libc
Differential Revision: https://reviews.llvm.org/D111516
Fixes the tests added in D110852 for the debug iterators.
Similar issues with hijacking `operator&` still exist, they will be
addressed separately.
Reviewed By: #libc, ldionne, Quuxplusone
Differential Revision: https://reviews.llvm.org/D111564
While looking at LWG-2988 and P0558 it seems the issues were already
implemented, but the synopsis wasn't updated. Some of the tests didn't
validate the `noexcept` status. A few tests were missing completely:
- `atomic_wait_explicit`
- `atomic_notify_one`
- `atomic_notify_all`
Mark P0558 as complete, didn't investigate which version of libc++ first
includes this. It seems the paper has been retroactively applied. I
couldn't find whether this is correct, but looking at cppreference it
seems intended.
Completes
- LWG-2988 Clause 32 cleanup missed one typename
- P0558 Resolving atomic<T> named base class inconsistencies
Reviewed By: #libc, ldionne
Differential Revision: https://reviews.llvm.org/D103765
Some embedded platforms do not wish to support the C library functionality
for handling wchar_t because they have no use for it. It makes sense for
libc++ to work properly on those platforms, so this commit adds a carve-out
of functionality for wchar_t.
Unfortunately, unlike some other carve-outs (e.g. random device), this
patch touches several parts of the library. However, despite the wide
impact of this patch, I still think it is important to support this
configuration since it makes it much simpler to port libc++ to some
embedded platforms.
Differential Revision: https://reviews.llvm.org/D111265
Implement P2401 which adds a `noexcept` specification to
`std::exchange`. Treated as a defect fix which is the motivation for
applying this change to all standards mode rather than just C++23 or
later as the paper suggests.
Reviewed By: Quuxplusone, Mordante, #libc
Differential Revision: https://reviews.llvm.org/D111481
There is an empty `namespace std` in `type_traits` which was originally
used when `std::byte` was added in
c97d8aa866. At some point, the bitwise operators
on `std::byte` got relocated but this empty namespace was left around.
Remove it.
Reviewed By: Quuxplusone, Mordante, #libc
Differential Revision: https://reviews.llvm.org/D111512
Implement parts of P1614, including three-way comparison for tuples, and expand testing.
Reviewed By: ldionne, Mordante, #libc
Differential Revision: https://reviews.llvm.org/D108250
While looking at the review comments in D103765 there was an oddity in
the tests for the following functions:
- atomic_fetch_add
- atomic_fetch_add_explicit
- atomic_fetch_sub
- atomic_fetch_sub_explicit
Libc++ allows usage of
`atomic_fetch_add<int>(atomic<int*>*, atomic<int*>::difference_type);`
MSVC and GCC reject this code: https://godbolt.org/z/9d8WzohbE
This makes the atomic `fetch(add|sub).*` Standard conforming and removes the non-conforming extensions.
Fixes PR47908
Reviewed By: ldionne, #libc
Differential Revision: https://reviews.llvm.org/D103983
Replace `&__rhs` with `_VSTD::addressof(__rhs)` to guard against ADL hijacking
of `operator&` in `operator=`. Thanks to @CaseyCarter for bringing it to our
attention.
Similar issues with hijacking `operator&` still exist, they will be
addressed separately.
Reviewed By: #libc, Quuxplusone, ldionne
Differential Revision: https://reviews.llvm.org/D110852
Implements the formatter for Boolean types.
[format.formatter.spec]/2.3
For each charT, for each cv-unqualified arithmetic type ArithmeticT other
than char, wchar_t, char8_t, char16_t, or char32_t, a specialization
```
template<> struct formatter<ArithmeticT, charT>;
```
This removes the stub implemented in D96664.
Implements parts of:
- P0645 Text Formatting
- P1652 Printf corner cases in std::format
Completes:
- P1868 width: clarifying units of width and precision in std::format
Reviewed By: #libc, ldionne
Differential Revision: https://reviews.llvm.org/D103670
Implements the formatter for all fundamental integer types.
[format.formatter.spec]/2.1
The specializations
```
template<> struct formatter<char, char>;
template<> struct formatter<char, wchar_t>;
template<> struct formatter<wchar_t, wchar_t>;
```
This removes the stub implemented in D96664.
Implements parts of:
- P0645 Text Formatting
Reviewed By: #libc, ldionne
Differential Revision: https://reviews.llvm.org/D103466
Implements the formatter for all fundamental integer types
(except `char`, `wchar_t`, and `bool`).
[format.formatter.spec]/2.3
For each charT, for each cv-unqualified arithmetic type ArithmeticT other
than char, wchar_t, char8_t, char16_t, or char32_t, a specialization
```
template<> struct formatter<ArithmeticT, charT>;
```
This removes the stub implemented in D96664.
As an extension it adds partial support for 128-bit integer types.
Implements parts of:
- P0645 Text Formatting
- P1652 Printf corner cases in std::format
Completes:
- LWG-3248 #b, #B, #o, #x, and #X presentation types misformat negative numbers
Reviewed By: #libc, ldionne, vitaut
Differential Revision: https://reviews.llvm.org/D103433
Implements the formatter for all string types.
[format.formatter.spec]/2.2
For each charT, the string type specializations
```
template<> struct formatter<charT*, charT>;
template<> struct formatter<const charT*, charT>;
template<size_t N> struct formatter<const charT[N], charT>;
template<class traits, class Allocator>
struct formatter<basic_string<charT, traits, Allocator>, charT>;
template<class traits>
struct formatter<basic_string_view<charT, traits>, charT>;
```
This removes the stub implemented in D96664.
Implements parts of:
- P0645 Text Formatting
- P1868 width: clarifying units of width and precision in std::format
Reviewed By: #libc, ldionne, vitaut
Differential Revision: https://reviews.llvm.org/D103425
Priorities below 101 are reserved for the implementation, so that's what
we should be using here. That is unfortunately only supported on more
recent versions of Clang. See https://reviews.llvm.org/D31413 for details.
Differential Revision: https://reviews.llvm.org/D95972
Implement P1391 (https://wg21.link/p1391) which allows
`std::string_view` to be constructible from any contiguous range of
characters.
Note that a different paper (http://wg21.link/P1989) handles the generic
range constructor for `std::string_view`.
Reviewed By: ldionne, Quuxplusone, Mordante, #libc
Differential Revision: https://reviews.llvm.org/D110718
In basic_string and vector, we've been encapsulating all exception
throwing code paths in helper functions of a base class, which are defined
in the compiled library. For example, __vector_base_common defines two
methods, __throw_length_error() and __throw_out_of_range(), and the class
is externally instantiated in the library. This was done a long time ago,
but after investigating, I believe the goal of the current design was to:
1. Encapsulate the code to throw an exception (which is non-trivial) in
an externally-defined function so that the important code paths that
call it (e.g. vector::at) are free from that code. Basically, the
intent is for the "hot" code path to contain a single conditional jump
(based on checking the error condition) to an externally-defined function,
which handles all the exception-throwing business.
2. Avoid defining this exception-throwing function once per instantiation
of the class template. In other words, we want a single copy of
__throw_length_error even if we have vector<int>, vector<char>, etc.
3. Encapsulate the passing of the container-specific string (i.e. "vector"
and "basic_string") to the underlying exception-throwing function
so that object files don't contain those duplicated string literals.
For example, we'd like to have a single "vector" string literal for
passing to `std::__throw_length_error` in the library, instead of
having one per translation unit.
However, the way this is achieved right now has two problems:
- Using a base class and exporting it is really weird - I've been confused
about this ever since I first saw it. It's just a really unusual way of
achieving the above goals. Also, it's made even worse by the fact that
the definitions of __throw_length_error and __throw_out_of_range appear
in the headers despite always being intended to be defined in the compiled
library (via the extern template instantiation).
- We end up exporting those functions as weak symbols, which isn't great
for load times. Instead, it would be better to export those as strong
symbols from the library.
This patch fixes those issues while retaining ABI compatibility (e.g. we
still export the exact same symbols as before). Note that we need to
keep the base classes as-is to avoid breaking the ABI of someone who
might inherit from std::basic_string or std::vector.
Differential Revision: https://reviews.llvm.org/D111173
e9ee517930 added support for using
winpthreads on Windows, enabled if `__WINPTHREADS_VERSION` was
defined (i.e. if winpthreads headers have been included before
including libcxx `__config`). This was fragile (libcxx changed
behaviour depending on what headers had been included externally
before), and was changed in a1bc823a59
to use pthreads on Windows whenever the pthread.h header was
available.
This is also fragile; pthread.h might be unavailable while building
libcxx but installed later, and available when users include the
libcxx headers.
In practice, in every modern setup for building libcxx for Windows
I've seen, users end up manually configuring it with
`LIBCXX_HAS_WIN32_THREAD_API=ON`, as the users may have winpthreads
installed (for other libraries/projects to use) while wanting to
build libcxx with the default win32 threading.
Don't automatically pick up pthreads on Windows even if the header
is available. Instead require the user to configure the libcxx
build with `LIBCXX_HAS_PTHREAD_API=ON` if that's desired.
Differential Revision: https://reviews.llvm.org/D110975
The existing tests for transform_view::iterator weren't quite right,
and can be simplified now that we have more of C++20 available to us.
Having done that, let's use the same pattern for iota_view::iterator
as well.
Differential Revision: https://reviews.llvm.org/D110774
This adds the width estimation functions to the std-format-spec.
Implements parts of:
- P0645 Text Formatting
- P1868 width: clarifying units of width and precision in std::format
Reviewed By: #libc, ldionne, vitaut
Differential Revision: https://reviews.llvm.org/D103413
This reverts part of commit b82683b2eb.
I hadn't intended to remove the `// -*- C++ -*-` comment line
from `libcxx/include/version`, only from the generated tests.
Thanks to Raul Tambre for the catch.
Even if these comments have a benefit in .h files (for editors that
care about language but can't be configured to treat .h as C++ code),
they certainly have no benefit for files with the .cpp extension.
Discussed in D110794.
Some of these were previously half-implemented in "ordering.h";
now they're all implemented, and tested.
Note that `constexpr` functions are implicitly `inline`, so the
standard wording omits `inline` on these; but Louis and I agree
that that's surprising and it's better to be explicit about it.
Differential Revision: https://reviews.llvm.org/D110515
Instead of using a base class to store the members and the optional
size, use [[no_unique_address]] to achieve the same thing without
needing a base class.
Also, as a fly-by:
- Change subrange from struct to class (per the standard)
- Improve the diagnostic for when one doesn't provide a size to the ctor of a sized subrange
- Replace this->member by just member since it's not in a dependent base anymore
This change would be an ABI break due to [[no_unique_address]], but we
haven't shipped ranges anywhere yet, so this shouldn't affect anyone.
Differential Revision: https://reviews.llvm.org/D110370
There's really no reason to even have two different enums here,
but *definitely* we shouldn't have *three*, and they don't need
so many synonymous enumerator values.
Differential Revision: https://reviews.llvm.org/D110516
In reaction to the issues raised by Richard in https://llvm.org/D109066,
this commit does not apply P1951 as a DR in previous standard modes,
since it breaks valid code.
I do believe it should be applied as a DR, however ideally we'd get some
sort of statement from the Committee to this effect (and all implementations
would behave consistently). In the meantime, only implement P1951 starting
with C++23 -- we can always come back and apply it as a DR if that's what
the Committee says.
Differential Revision: https://reviews.llvm.org/D110347
That macro was being defined but not used anywhere in libc++, so it
must be safe to remove it.
As a fly-by fix, also remove mentions of this macro in other places
in LLVM, to make sure they were not depending on the value defined in
libc++.
Differential Revision: https://reviews.llvm.org/D110289
Implements parts of P1614, including synth-three-way and three way comparison for std::pair.
Reviewed By: #libc, Quuxplusone, Mordante
Differential Revision: https://reviews.llvm.org/D107721
Instead of overloading `__to_address`, let's specialize `pointer_traits`.
Function overloads need to be in scope at the point where they're called,
whereas template specializations do not. (User code can provide pointer_traits
specializations to be used by already-included library code, so obviously
`__wrap_iter` can do the same.)
`pointer_traits<__wrap_iter<It>>` cannot provide `pointer_to`, because
you generally cannot create a `__wrap_iter` without also knowing the
identity of the container into which you're trying to create an iterator.
I believe this is OK; contiguous iterators are required to provide
`to_address` but *not* necessarily `pointer_to`.
Differential Revision: https://reviews.llvm.org/D110198
All supported compilers provide support for inline variables in C++17 now.
Also, as a fly-by fix, replace some uses of _LIBCPP_CONSTEXPR by just
constexpr.
The only exception in this patch is `std::ignore`, which is provided
prior to C++17. Since it is defined in an anonymous namespace, it always
has internal linkage anyway, so using an inline variable there doesn't
provide any benefit. Instead, `inline` was removed entirely on `std::ignore`.
Differential Revision: https://reviews.llvm.org/D110243
