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
Generally these calls aren't vulnerable to ADL because they involve only
primitive types. The ones in <list> and <vector> drag in namespace std
but that's OK; the ones in <fstream> and <strstream> are vulnerable
iff `CharT` is an enum type, which seems far-fetched.
But absolutely zero of them *need* ADL to happen; so in my opinion
they should all be consistently qualified, just like calls to any
other (non-user-customizable) functions in namespace std.
Also: Include <cstring> and <cwchar> in <__string>.
We seemed to be getting lucky that <memory> included <iterator>
included <iosfwd> included <wchar.h>. That gave us the
global-namespace `wmemmove`, but not `_VSTD::wmemmove`.
This is now fixed.
I didn't touch these headers:
<ext/__hash> uses strlen, safely
<support/ibm/locale_mgmt_aix.h> uses memcpy, safely
<string.h> uses memchr and strchr, safely
<wchar.h> uses wcschr, safely
<__bsd_locale_fallbacks.h> uses wcsnrtombs, safely
Differential Revision: https://reviews.llvm.org/D93061
This matches how libc++ does it in all other C++ headers
(that is, headers not ending in ".h").
We need to include <cstring> if we want to use `_VSTD::memmove`
instead of unqualified ADL `memmove`. Even though ADL doesn't
physically matter in <charconv>'s specific case, I'm trying
to migrate libc++ to using `_VSTD::memmove` for all cases
(because some of them do matter, and this way it's easier to
grep for outliers).
Differential Revision: https://reviews.llvm.org/D92875
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.
Idea from D92525.
This script globs include/ directory and updates the tests in test/libcxx.
This patch does not generate module.modulemap nor CMakeLists.txt.
Reviewed By: ldionne, #libc
Differential Revision: https://reviews.llvm.org/D92656
This attribute permits a typedef to be associated with a class template
specialization as a preferred way of naming that class template
specialization. This permits us to specify that (for example) the
preferred way to express 'std::basic_string<char>' is as 'std::string'.
The attribute is applied to the various class templates in libc++ that have
corresponding well-known typedef names.
This is a re-commit. The previous commit was reverted because it exposed
a pre-existing bug that has since been fixed / worked around; see
PR48434.
Differential Revision: https://reviews.llvm.org/D91311
The goal was to add coverage for back-deployment over the filesystem
library, but it was added in macOS 10.15, not 10.14.
Differential Revision: https://reviews.llvm.org/D92937
The interesting change here is that we no longer consider `__convert_to_integral`
an ADL customization point for the user's types. I think the new behavior
is defensible. The old behavior had come from D7449, where Marshall explicitly
said "people can't define their own [`__convert_to_integral` overloads]."
Differential Revision: https://reviews.llvm.org/D92814
It adds coverage for back-deploying to a system that contains the
filesystem library, which 10.9 (currently our only back-deployment
target in the CI) does not have.
Differential Revision: https://reviews.llvm.org/D92794
This change exposed a pre-existing issue with deserialization cycles
caused by a combination of attributes and template instantiations
violating the deserialization ordering restrictions; see PR48434 for
details.
A previous commit attempted to work around PR48434, but appears to have
only been a partial fix, and fixing this properly seems non-trivial.
Backing out for now to unblock things.
This reverts commit 98f76adf4e and
commit a64c26a47a.
This attribute permits a typedef to be associated with a class template
specialization as a preferred way of naming that class template
specialization. This permits us to specify that (for example) the
preferred way to express 'std::basic_string<char>' is as 'std::string'.
The attribute is applied to the various class templates in libc++ that have
corresponding well-known typedef names.
Differential Revision: https://reviews.llvm.org/D91311
The issue didn't change the behaviour which is tested in libcxx/test/std/input.output/filesystems/class.path/path.member/path.concat.pass.cpp.
The change to use string_view instead of string is not strictly necessary.
<filesystem> was added in commit 998a5c8831 (Implement <filesystem>).
Reviewed By: #libc, ldionne
Differential Revision: https://reviews.llvm.org/D92731
This is the the minimal change introduced in [[ https://reviews.llvm.org/D88599 | D88599 ]] to unblock the controversial change and discussion of proper separation between thread from thread id which will continue in D88599.
This patch will address the differences of definition of pthread_t on z/OS vs. Linux and other OS. Main trick to make the code work on z/OS relies on redefining libcpp_thread_id type and _LIBCPP_NULL_THREAD macro. This is necessary to separate initialization of libcxx_thread_id from the one of __libcxx_thread_t;
Reviewed By: #libc, ldionne
Differential Revision: https://reviews.llvm.org/D91875
The synopsis now reflects what's implemented. It does NOT reflect
all of what's specified in C++20. The "constexpr in C++20" markings
are still missing from these 12 algorithms, because they are still
unimplemented by libc++:
reverse partition sort nth_element next_permutation prev_permutation
push_heap pop_heap make_heap sort_heap partial_sort partial_sort_copy
All of the above algorithms were excluded from [P0202].
All of the above algorithms were made constexpr in [P0879] (along with
swap_ranges, iter_swap, and rotate — we've already implemented those three).
Differential Revision: https://reviews.llvm.org/D92255
These had been waiting on the ability to use `std::copy` from
constexpr code (which in turn had been waiting on the ability to
use `is_constant_evaluated()` to switch between `memmove` and non-`memmove`
implementations of `std::copy`). That work landed a while ago,
so these algorithms can all be constexpr in C++20 now.
Simultaneously, update the tests for the set algorithms.
- Use an element type with "equivalent but not identical" values.
- The custom-comparator tests now pass something different from `operator<`.
- Make the constexpr coverage match the non-constexpr coverage.
Differential Revision: https://reviews.llvm.org/D92255
previously, invocations of std::sort(T**, T**) casted the arguments to
(size_t *). this breaks sorting on systems for which pointers don't fit
in a size_t. change the cast to (uintptr_t *) and add a test.
Differential Revision: https://reviews.llvm.org/D92190
It was added in commit 0b71bf7939, "[libcxx] [test] Add a test for conversions between wchar_t, utf8, char16_t, char32_t and windows native narrow code pages"
This implements the std::filesystem parts of P0482 (which is already
marked as in progress), and applies the actions that are suggested
in P1423.
Differential Revision: https://reviews.llvm.org/D90222
Some C++20 headers weren't added properly to all three of these
test files. Add them, and take the time to normalize the formatting
so that
diff <(grep '#include' foo.cpp) <(grep '#include' bar.cpp)
shows no diffs (except that `no_assert_include` deliberately
excludes `<cassert>`).
- Add macro guards to <{barrier,latch,semaphore}>.
- Add macro guards to <experimental/simd>.
- Remove an include of <cassert> from <semaphore>.
- Instead, include <cassert> in the semaphore tests.
Differential Revision: https://reviews.llvm.org/D92525
Also:
* Fix header line in all status tables.
* Use C++20 instead of C++2a.
Reviewed By: ldionne, #libc, miscco
Differential Revision: https://reviews.llvm.org/D92306
Also, add notes about exporting ABI symbols.
Later, we can add notes about using git-clang-format before sending a patch for review.
Reviewed By: ldionne, #libc
Differential Revision: https://reviews.llvm.org/D92300
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
Richard Smith