This will allow us to use variant in common_iterator. We do this by introducing a new `__light_array` type that variant uses instead of `std::array`.
Differential Revision: https://reviews.llvm.org/D105597
The format library uses `std::monostate`, but not a `std::variant`.
Moving `std::monostate` to its own header allows the format library to
reduce the amount of included code.
Reviewed By: #libc, ldionne
Differential Revision: https://reviews.llvm.org/D105582
Summary:
If we are on c++03 mode for some reason, and __builtin_va_copy is
available, then use it instead of error out on not having va_copy
in 03 mode.
Reviewed by: ldionne
Differential Revision: https://reviews.llvm.org/D100336
While we can debate on the value of passing by const value, there is no
arguing that it's confusing to do so in some circumstances, such as when
marking a pointer parameter as being const (did you mean a pointer-to-const?).
This commit fixes a few issues along those lines.
The __search helper function was once split into __functional for circular
dependency reasons, however this is not an issue anymore now that we have
finer grained headers.
With the STL containers, I didn't enable move operations in C++03 mode
because that would change the overload resolution for things that today
are copy operations. With iostreams, though, the copy operations aren't
present at all, and so I see no problem with enabling move operations
even in (Clang's greatly extended) C++03 mode.
Clang's C++03 mode does not support delegating constructors.
Differential Revision: https://reviews.llvm.org/D104310
In typeinfo there is a reinterpret_cast between a uintptr_t and size_t. These are two integer types and therefore a reinterpret_cast is not right for this situation. It looks like it may have been copied and pasted from above in the file. An implicit cast works in it's place.
Reviewed By: ldionne, #libc
Differential Revision: https://reviews.llvm.org/D104814
Moves:
* `std::move`, `std::forward`, `std::declval`, and `std::swap` into
`__utility/${FUNCTION_NAME}`.
* `std::swap_ranges` and `std::iter_swap` into
`__algorithm/${FUNCTION_NAME}`
Differential Revision: https://reviews.llvm.org/D103734
Under the as-if rule, we can directly implement the array overload for
`std::swap`. By removing this circular dependency where `swap` is
implemented in terms of `swap_ranges` and `swap_ranges` is defined in
terms of `swap`, we can split them into their own headers. This will:
* limit the surface area in which Hyrum's law can bite us;
* force users to include the correct headers;
* make finding the definitions trivial (`swap` is a utility;
`swap_ranges` is an algorithm).
Differential Revision: https://reviews.llvm.org/D104760
* `<type_traits>` depends on `std::forward`, so we replaced it with
`static_cast<T&&>`.
* `swap`'s return type is confusing, so it's been rearranged to improve
readabilitiy.
C++03 didn't support `explicit` conversion operators;
but Clang's C++03 mode does, as an extension, so we can use it.
This lets us make the conversion explicit in `std::function` (even in '03),
and remove some silly metaprogramming in `std::basic_ios`.
Drive-by improvements to the tests for these operators, in addition
to making sure all these tests also run in `c++03` mode.
Differential Revision: https://reviews.llvm.org/D104682
The current implementation of `std::forward_list::swap` uses
`propagate_on_container_move_assignment` for `noexcept` specification.
This patch changes it to use `propagate_on_container_swap`, as it should.
Fixes https://llvm.org/PR50224.
Differential Revision: https://reviews.llvm.org/D101899
This is a fairly mechanical change, it just moves each algorithm into
its own header. This is intended to be a NFC.
This commit re-applies 7ed7d4ccb8, which was reverted in 692d7166f7
because the Modules build got broken. The modules build has now been
fixed, so we're re-committing this.
Differential Revision: https://reviews.llvm.org/D103583
Attribution note
----------------
I'm only committing this. This commit is a mix of D103583, D103330 and
D104171 authored by:
Co-authored-by: Christopher Di Bella <cjdb@google.com>
Co-authored-by: zoecarver <z.zoelec2@gmail.com>
P1518 does the following in C++23 but we'll just do it in C++17 as well:
- Stop requiring `Alloc` to be an allocator on some container-adaptor deduction guides
- Stop deducing from `Allocator` on some sequence container constructors
- Stop deducing from `Allocator` on some other container constructors (libc++ already did this)
The affected constructors are the "allocator-extended" versions of
constructors where the non-allocator arguments are already sufficient
to deduce the allocator type. For example,
std::pmr::vector<int> v1;
std::vector v2(v1, std::pmr::new_delete_resource());
std::stack s2(v1, std::pmr::new_delete_resource());
Differential Revision: https://reviews.llvm.org/D97742
When we removed the allocator<void> specialization, the triviality of
std::allocator<void> changed because the primary template had a
non-trivial default constructor and the specialization didn't
(so std::allocator<void> went from trivial to non-trivial).
This commit fixes that oversight by giving a trivial constructor to
the primary template when instantiated on cv-void.
This was reported in https://llvm.org/PR50299.
Differential Revision: https://reviews.llvm.org/D104398
A few slipped through the cracks because D104175 and D104170 didn't
concern themselves with newer commits.
Differential Revision: https://reviews.llvm.org/D104414
While the std::allocator<void> specialization was deprecated by
https://wg21.link/p0174#2.2, the *use* of std::allocator<void> by users
was not. The intent was that std::allocator<void> could still be used
in C++17 and C++20, but starting with C++20 (with the removal of the
specialization), std::allocator<void> would use the primary template.
That intent was called out in wg21.link/p0619r4#3.9.
As a result of this patch, _LIBCPP_ENABLE_CXX20_REMOVED_ALLOCATOR_MEMBERS
will also not control whether the explicit specialization is provided or
not. It shouldn't matter, since in C++20, one can simply use the primary
template.
Fixes http://llvm.org/PR50299
Differential Revision: https://reviews.llvm.org/D104323
This has been broken out of D104170 since it should be merged whether or
not we go ahead with the module map changes.
Differential Revision: https://reviews.llvm.org/D104175
https://eel.is/c++draft/atomics.types.operations#23 says: ... the value of failure is order except that a value of `memory_order::acq_rel` shall be replaced by the value `memory_order::acquire` and a value of `memory_order::release` shall be replaced by the value `memory_order::relaxed`.
This failure mapping is only handled for `_LIBCPP_HAS_GCC_ATOMIC_IMP`. We are seeing bad code generation for `compare_exchange_strong(cmp, 1, std::memory_order_acq_rel)` when using libc++ in place of libstdc++: https://godbolt.org/z/v3onrrq4G.
This was caught by tsan tests after D99434, `[TSAN] Honor failure memory orders in AtomicCAS`, but appears to be an issue in non-tsan code.
Reviewed By: ldionne, dvyukov
Differential Revision: https://reviews.llvm.org/D103846
Louis Dionne