As mandated by the Standard's various synopses, e.g. [iterator.synopsis].
Searching the TeX source for '#include' is a good way to find all of these
mandates.
The new tests are all autogenerated by utils/generate_header_inclusion_tests.py.
I was SHOCKED by how many mandates there are, and how many of them
libc++ wasn't conforming with.
Differential Revision: https://reviews.llvm.org/D99309
This patch implements 2802. Requires _Deleter to have call operator and be move constructible. Based on D62233.
Refs PR37637.
Differential Revision: https://reviews.llvm.org/D62274
- Implement C++20's changes to `reverse_iterator`, so that it won't be
accidentally counted as a contiguous iterator in C++20 mode.
- Implement C++20's changes to `move_iterator` as well.
- `move_iterator` should not be contiguous. This fixes a bug where
we optimized `std::copy`-of-move-iterators in an observable way.
Add a regression test for that bugfix.
- Add libcxx tests for `__is_cpp17_contiguous_iterator` of all relevant
standard iterator types. Particularly check that vector::iterator
is still considered contiguous in all C++ modes, even C++03.
After this patch, there continues to be no supported way to write your
own iterator type in C++17-and-earlier such that libc++ will consider it
"contiguous"; however, we now fully support the C++20 approach (in C++20
mode only). If you want user-defined contiguous iterators in C++17-and-earlier,
libc++'s position is "please upgrade to C++20."
Differential Revision: https://reviews.llvm.org/D94807
The implementation had a lot of boilerplate and was more complicated than
necessary. This NFC refactoring introduces a few macros to reduce code
duplication, and uses a consistent style and formatting for the whole file.
Differential Revision: https://reviews.llvm.org/D94544
This patch updates `allocate_shared` to call `allocator_traits::construct`
when creating the object held inside the shared_pointer, and
`allocator_traits::destroy` when destroying it. This resolves
the part of P0674R1 that was originally filed as LWG2070.
This change is landed separately from the rest of P0674R1 because it is
incredibly tricky from an ABI perspective.
This is the reason why this change is so tricky is that we previously
used EBO in a compressed pair to store both the allocator and the object
type stored in the `shared_ptr`. However, starting in C++20, P0674
requires us to use Allocator construction for initializing the object type.
That requirement rules out the use of the EBO for the object type, since
using the EBO implies that the base will be initialized when the control
block is initialized (and hence we can't do it through Allocator construction).
Hence, supporting P0674 requires changing how we store the object type
inside the control block, which we do while being ABI compatible by using
some trickery with a properly aligned char buffer.
Fixes https://llvm.org/PR41900
Supersedes https://llvm.org/D62760
Differential Revision: https://reviews.llvm.org/D91201
Checking that `T` is constructible from `Args...` is technically not
required by the Standard, although any implementation will obviously
error out if that's not satisfied. However, this check is incompatible
with using Allocator construction in the control block (upcoming change
as part of implementing P0674), so I'm removing it now to reduce the
upcoming diff as much as possible.
Differential Revision: https://reviews.llvm.org/D93246
This commit is a step towards making it easier to add support for arrays
in allocate_shared. Adding support for arrays will require writing multiple
functions, and the current complexity of writing allocate_shared is
prohibitive for understanding.
Differential Revision: https://reviews.llvm.org/D93130
In addition to making the code a lot easier to grasp by localizing many
helper functions to the only file where they are actually needed, this
will allow creating helper functions that depend on allocator_traits
outside of <memory>.
This is done as part of implementing array support in allocate_shared,
which requires non-trivial array initialization algorithms that would be
better to keep out of <memory> for sanity. It's also a first step towards
splitting up our monolithic headers into finer grained ones, which will
make it easier to reuse functionality across the library. For example,
it's just weird that we had to define `addressof` inside <type_traits>
to avoid circular dependencies -- instead it's better to implement those
in true helper headers.
Differential Revision: https://reviews.llvm.org/D93074
Everywhere, normalize the whitespace to `::new (EXPR) T`.
Everywhere, normalize the spelling of the cast to `(void*)EXPR`.
Without the cast to `(void*)`, the expression triggers ADL on GCC.
(I think this is a GCC bug: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98249)
Even if it doesn't trigger ADL, it still seems incorrect to use any argument
that's not exactly `(void*)` because that opens the possibility of overload
resolution picking a user-defined overload of `operator new`, which would be
wrong.
Differential Revision: https://reviews.llvm.org/D93153
This simplifies the implementation, and it appears to be equivalent since
make_shared was allocating memory with std::allocator anyway.
Differential Revision: https://reviews.llvm.org/D93071
This is the first of a series of patches leading up to the implementation
of P0674r1, i.e. array support in allocate_shared. I am splitting this
up into multiple patches because the overall change is very tricky and
I want to isolate potential breakage.
The static_assert in "libcxx/include/memory" was the main offender here,
but then I figured I might as well `git grep -i instantat` and fix all
the instances I found. One was in user-facing HTML documentation;
the rest were in comments or tests.
I used a lot of `git grep` to find places where `std::` was being used
outside of comments and assert-messages. There were three outcomes:
- Qualified function calls, e.g. `std::move` becomes `_VSTD::move`.
This is the most common case.
- Typenames that don't need qualification, e.g. `std::allocator` becomes `allocator`.
Leaving these as `_VSTD::allocator` would also be fine, but I decided
that removing the qualification is more consistent with existing practice.
- Names that specifically need un-versioned `std::` qualification,
or that I wasn't sure about. For example, I didn't touch any code in
<atomic>, <math.h>, <new>, or any ext/ or experimental/ headers;
and I didn't touch any instances of `std::type_info`.
In some deduction guides, we were accidentally using `class Alloc = typename std::allocator<T>`,
despite `std::allocator<T>`'s type-ness not being template-dependent.
Because `std::allocator` is a qualified name, this did parse as we intended;
but what we meant was simply `class Alloc = allocator<T>`.
Differential Revision: https://reviews.llvm.org/D92250
This reverts commit 620adacf87.
Fix: unsupport C++03 for the new test, define helpers before __swap_allocator
(1) Add _VSTD:: qualification to __swap_allocator.
(2) Add _VSTD:: qualification consistently to __to_address.
(3) Add some more missing _VSTD:: to <vector>, with a regression test.
This part is cleanup after d9a4f936d0.
Note that a vector whose allocator actually runs afoul of any of these ADL calls will
likely also run afoul of simple things like `v1 == v2` (which is also an ADL call).
But, still, libc++ should be consistent in qualifying function calls wherever possible.
Relevant blog post: https://quuxplusone.github.io/blog/2019/09/26/uglification-doesnt-stop-adl/
Differential Revision: https://reviews.llvm.org/D91708
(1) Add _VSTD:: qualification to __swap_allocator.
(2) Add _VSTD:: qualification consistently to __to_address.
(3) Add some more missing _VSTD:: to <vector>, with a regression test.
This part is cleanup after d9a4f936d0.
Note that a vector whose allocator actually runs afoul of any of these ADL calls will
likely also run afoul of simple things like `v1 == v2` (which is also an ADL call).
But, still, libc++ should be consistent in qualifying function calls wherever possible.
Relevant blog post: https://quuxplusone.github.io/blog/2019/09/26/uglification-doesnt-stop-adl/
Differential Revision: https://reviews.llvm.org/D91708
Currently, vendor-specific availability markup is enabled by default.
This means that even when building against trunk libc++, the headers
will by default prevent you from using some features that were not
released in the dylib on your target platform. This is a source of
frustration since people building libc++ from sources are usually not
trying to use some vendor's released dylib.
For that reason, I've been thinking for a long time that availability
annotations should be off by default, which is the primary change that
this commit enables.
In addition, it reworks the implementation to make it easier for new
vendors to add availability annotations for their platform, and it
refreshes the documentation to reflect the current state of the codebase.
Finally, a CMake configuration option is added to control whether
availability annotations should be turned on for the flavor of libc++
being created. The intent is for vendors like Apple to turn it on, and
for the upstream libc++ to leave it off (the default).
Differential Revision: https://reviews.llvm.org/D90843
This patch ensures that __shared_weak_count provides a consistent vtable
regardless of if RTTI is enabled or if we are targeting a static or shared
libc++ build.
This patch is technically ABI breaking, but only for a very specific
configuration that no vendor should be shipping.
Note that _LIBCPP_BUILD_STATIC is not normally defined when building
libc++.a, but instead it must be manually provided by the user or the
__config_site.
Differential Revision: https://reviews.llvm.org/D32838
We're technically not allowed by the Standard to call ::operator new in
constexpr functions like __libcpp_allocate. Clang doesn't seem to complain
about it, but GCC does.
This commit adds std::construct_at, and marks various members of
std::allocator_traits and std::allocator as constexpr. It also adds
tests and turns the existing tests into hybrid constexpr/runtime tests.
Thanks to Richard Smith for initial work on this, and to Michael Park
for D69803, D69132 and D69134, which are superseded by this patch.
Differential Revision: https://reviews.llvm.org/D68364
We don't support GCC in C++03 mode, and Clang provides variadic templates
even in C++03 mode. So there's effectively no supported compiler that
doesn't support variadic templates.
This effectively gets rid of all uses of _LIBCPP_HAS_NO_VARIADICS, but
some workarounds for the lack of variadics remain.
This implements the part of P0619R4 related to the default allocator.
This is incredibly important, since otherwise there is an ABI break
between C++17 and C++20 w.r.t. the default allocator's size_type on
platforms where std::size_t is not the same as std::make_unsigned<std::ptrdiff_t>.
We don't support GCC in C++03 mode, and Clang provides rvalue references
even in C++03 mode. So there's effectively no supported compiler that
doesn't support rvalue references.
Differential Revision: https://reviews.llvm.org/D84943
All compilers supported by libc++ have rvalues in C++03 mode so, there is no need for this non-rvalue overload.
Differential Revision: https://reviews.llvm.org/D80881
Louis Dionne