* <__algorithm/iter_swap.h>
* <__algorithm/swap_ranges.h>
* <__functional/is_transparent.h>
* <__memory/uses_allocator.h>
* <__ranges/drop_view.h>
* <__ranges/transform_view.h>
* <shared_mutex>
* <span>
Also updates header inclusions that were affected.
**NOTE:** This is a proper subset of D105932. Since the content has
already been LGTM'd, I intend to merge this patch without review,
pending green CI. I decided it would be better to move these changes
into their own commit since the former patch has undergone further
changes and will need yet another light review. In the event any of
that gets rolled back (for whatever reason), the changes in this patch
won't be affected.
Differential Revision: https://reviews.llvm.org/D106040
This configuration is interesting because GCC has a different level of
strictness for some C++ rules. In particular, it implements the older
standards more stringently than Clang, which can help find places where
we are non-conforming (especially in the test suite).
Differential Revision: https://reviews.llvm.org/D105936
The XFAIL comments about VCRuntime not providing aligned operator new
are outdated; these days VCRuntime does provide them.
However, the tests used to fail on Windows, as the pointers allocated
with an aligned operator new (which is implemented with _aligned_malloc
on Windows) can't be freed using std::free() on Windows (but they need
to be freed with the corresponding function _aligned_free instead).
Instead override the aligned operator new to return a dummy suitably
aligned pointer instead, like other tests that override aligned operator
new.
Also override `operator delete[]` instead of plain `operator delete`
in the array testcase; the fallback from `operator delete[]` to
user defined `operator delete` doesn't work in all DLL build
configurations on Windows.
Also expand the TEST_NOEXCEPT macros, as these tests only are built
in C++17 mode.
By providing the aligned operator new within the tests, this also makes
these test cases pass when testing back deployment on macOS 10.9.
Differential Revision: https://reviews.llvm.org/D105962
It turns out that D105040 broke `std::rel_ops`; we actually do need
both a one-template-parameter and a two-template-parameter version of
all the comparison operators, because if we have only the heterogeneous
two-parameter version, then `x > x` is ambiguous:
template<class T, class U> int f(S<T>, S<U>) { return 1; }
template<class T> int f(T, T) { return 2; } // rel_ops
S<int> s; f(s,s); // ambiguous between #1 and #2
Adding the one-template-parameter version fixes the ambiguity:
template<class T, class U> int f(S<T>, S<U>) { return 1; }
template<class T> int f(T, T) { return 2; } // rel_ops
template<class T> int f(S<T>, S<T>) { return 3; }
S<int> s; f(s,s); // #3 beats both #1 and #2
We have the same problem with `reverse_iterator` as with `__wrap_iter`.
But so do libstdc++ and Microsoft, so we're not going to worry about it.
Differential Revision: https://reviews.llvm.org/D105894
std::exchange is only constexpr in C++20 and later. We were using it
in a constructor marked unconditionally constexpr, which caused issues
when building with -std=c++17.
The weird part is that the issue only showed up when building on the
arm64 macs, but that must be caused by the specific version of Clang
used on those. Since the code is clearly wrong and the fix is obvious,
I'm not going to investigate this further.
Make sure that the detached thread has started up before exiting
the process.
This is exactly the same fix as D105592, with the same pattern
being present in a different test case.
Differential Revision: https://reviews.llvm.org/D105736
The unit tests test some implementation details. As @Quuxplusone pointed
out in D96664 this should only be tested when the tests use libc++. This
addresses the issue for code already in main.
Reviewed By: #libc, ldionne
Differential Revision: https://reviews.llvm.org/D105568
Make sure that the detached thread has started up before exiting
the process.
If the detached thread hasn't started up at all, and the main thread
exits, global data structures in the process are torn down, which
then can cause crashes when the thread starts up late after required
mutexes have been destroyed. (In particular, the mutex used internally
in _Init_thread_header, which is used in the initialization of
__thread_local_data()::__p, can cause crashes if the main thread already
has finished and progressed far with destruction.)
Differential Revision: https://reviews.llvm.org/D105592
Now that Lit supports regular expressions inside XFAIL & friends, it is
much easier to write Lit annotations based on the triple.
Differential Revision: https://reviews.llvm.org/D104747
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.
This patch is to fix 2 libcxx test cases, test cases assumed 'a' > 'A' which is not case in z/OS platform on ebcdic mode, modified test cases to compare between upper letters or lower letters, or digits so ordering will be true for all platform.
Differential Revision: https://reviews.llvm.org/D104748
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
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
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
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
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
Also, fix the last issue that prevented GCC 11 from passing the test
suite. Thanks to everyone else who fixed issues.
Differential Revision: https://reviews.llvm.org/D104315
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
This started as an attempt to fix a GCC 11 warning of misplaced parentheses.
I then noticed that trying to fix the parentheses warning actually triggered
errors in the tests, showing that we were incorrectly assuming that the
implementation of ranges::advance was using operator+= or operator-=.
This commit fixes that issue and makes the tests easier to follow by
localizing the assertions it makes.
Differential Revision: https://reviews.llvm.org/D103272
The synchronization library was marked as disabled on Apple platforms
up to now because we were not 100% sure that it was going to be ABI
stable. However, it's been some time since we shipped it in upstream
libc++ now and there's been no changes so far. This patch enables the
synchronization library on Apple platforms, and hence commits the ABI
stability as far as that vendor is concerned.
Differential Revision: https://reviews.llvm.org/D96790
Makes the following operations constexpr:
* `std::swap(optional, optional)`
* `optional(optional<U> const&)`
* `optional(optional<U>&&)`
* `~optional()`
* `operator=(nullopt_t)`
* `operator=(U&&)`
* `operator=(optional<U> const&)`
* `operator=(optional<U>&&)`
* `emplace(Args&&...)`
* `emplace(initializer_list<U>, Args&&...)`
* `swap(optional&)`
* `reset()`
P2231 has been accepted by plenary, with the committee recommending
implementers retroactively apply to C++20. It's necessary for us to
implement _`semiregular-box`_ and _`non-propagating-cache`_, both of
which are required for ranges (otherwise we'll need to reimplement
`std::optional` with these members `constexpr`ified).
Differential Revision: https://reviews.llvm.org/D102119
The post-conditions for the self move assignment of `std::unique_ptr`
were changed. This requires no implementation changes. A test was added
to validate the new post-conditions.
Addresses
- LWG-3455: Incorrect Postconditions on `unique_ptr` move assignment
Reviewed By: #libc, ldionne
Differential Revision: https://reviews.llvm.org/D103764
The `operator[]` of `_UnaryOp` and `_BinaryOp` returns the result of
calling `__op_`, so its return type should be `__result_type`, not
e.g. `_A0::value_type`. However, `_UnaryOp::value_type` also should
never have been `_A0::value_type`; it needs to be the correct type
for the result of the unary op, e.g. `bool` when the op is `logical_not`.
This turns out to matter when multiple operators are nested, e.g.
`+(v == v)` needs to have a `value_type` of `bool`, not `int`,
even when `v` is of type `valarray<int>`.
Differential Revision: https://reviews.llvm.org/D103416
This is a fairly mechanical change, it just moves each algorithm into its own header. This is a NFC.
Note: during this change, I burned down all the includes, so this follows "include only and exactly what you use."
Differential Revision: https://reviews.llvm.org/D103583
Since D100581, Clang started flagging this variable which is set but
never read. Based on comparing this function with __match_at_start_posix_nosubs
(which is very similar), I am pretty confident that `__j` was simply left
behind as an oversight in Howard's 6afe8b0a23.
Also workaround some unused variable warnings in the <random> tests.
It's pretty lame that we're not asserting the skew and kurtosis of
the binomial and negative binomial distributions, but that should be
tackled separately.
Differential Revision: https://reviews.llvm.org/D103533
This was added inconsistently in
19fd9039ca242f408493b5c662f9d908eab8555e; Windows doesn't have the
aligned_alloc function (neither MSVC nor MinGW toolchains) and we don't
define _LIBCPP_HAS_ALIGNED_ALLOC while building libcxx.
Differential Revision: https://reviews.llvm.org/D103399
This define was out of sync with the corresponding define in tests, it
was added inconsistently in 171c77b7da.
Modern MSVC environments do have these typedefs and functions.
Differential Revision: https://reviews.llvm.org/D103398
While the code uses the type name `std::mbstate_t`, the warning message
mentions the original underlying type, which is a C library internal
type name.
On Windows this type is called `_Mbstatet` instead of `__mbstate_t`. Use
expect-warning-re to avoid spelling out the literal name of the type.
Due to issues with the detection of the clang-verify feature, these
tests have been skipped in the Windows CI configuration so far.
Differential Revision: https://reviews.llvm.org/D103309
Make sure we provide the correct It::difference_type member and update
the tests and synopses to be accurate.
Supersedes D102657 and D103101 (thanks to the original authors).
Differential Revision: https://reviews.llvm.org/D103273
Due to issues with the detection of the clang-verify feature, these
tests have been skipped in the Windows CI configuration so far.
Differential Revision: https://reviews.llvm.org/D103308
This should have been done in D96385; thanks ldionne for the catch!
Also, make the back/front inserter behavior tests a little more thorough,
which incidentally caught a cut-and-paste-bug in `nasty_list`, so fix that.
Differential Revision: https://reviews.llvm.org/D103318
C++17 deprecated std::iterator and removed it as a base class for all
iterator adaptors. We implement that change, but we still provide a way
to inherit from std::iterator in the few cases where doing otherwise
would be an ABI break.
Supersedes D101729 and the std::iterator base parts of D103101 and D102657.
Differential Revision: https://reviews.llvm.org/D103171
Implements part of P0896 'The One Ranges Proposal'.
Implements [range.iter.op.prev].
Depends on D102563.
Differential Revision: https://reviews.llvm.org/D102564
Implements part of P0896 'The One Ranges Proposal'.
Implements [range.iter.op.next].
Depends on D101922.
Differential Revision: https://reviews.llvm.org/D102563
Ensures that `get_return_object`'s return type is the same as the return type for the function calling `co_return`. Otherwise, we try to construct an object, then free it, then return it.
Differential Revision: https://reviews.llvm.org/D103196
This also provides some of the scaffolding needed by D102992 and D101729, and mops up after D101730 etc.
Differential Revision: https://reviews.llvm.org/D103055
If the nested create_directory call fails, we'd still want to
re-report the errors with the create_directories function name,
which is what the caller called.
This fixes one aspect from MS STL's tests for std::filesystem.
Differential Revision: https://reviews.llvm.org/D102365
cxx20_iterator_traits.compile.pass.cpp actually depends on
implementation details of libc++, which is not great;
but I just left a comment and moved on.
This is the second to last one! Based on D101396. Depends on D100255. Refs D101079 and D101193.
Differential Revision: https://reviews.llvm.org/D101476
* adds `sized_range` and conformance tests
* moves `disable_sized_range` into namespace `std::ranges`
* removes explicit type parameter
Implements part of P0896 'The One Ranges Proposal'.
Differential Revision: https://reviews.llvm.org/D102434
Fix __bitop_unsigned_integer and rename to __libcpp_is_unsigned_integer.
There are only five unsigned integer types, so we should just list them out.
Also provide `__libcpp_is_signed_integer`, even though the Standard doesn't
consume that trait anywhere yet.
Notice that `concept uniform_random_bit_generator` is specifically specified
to rely on `concept unsigned_integral` and *not* `__is_unsigned_integer`.
Instantiating `std::ranges::sample` with a type `U` satisfying
`uniform_random_bit_generator` where `unsigned_integral<U::result_type>`
and not `__is_unsigned_integer<U::result_type>` is simply IFNDR.
Orthogonally, fix an undefined behavior in std::countr_zero(__uint128_t).
Orthogonally, improve tests for the <bit> manipulation functions.
It was these new tests that detected the bug in countr_zero.
Differential Revision: https://reviews.llvm.org/D102328
On windows, the native path char type is wchar_t - therefore, this test
didn't actually do the conversion that the test was supposed to exercise.
The charset conversions on windows do cause extra allocations outside of
the provided allocator though, so that bit of the test has to be waived
now that the test actually does something. (Other tests have similar
TEST_NOT_WIN32() for allocation checks for charset conversions.)
Also fix a typo, and amend the path.native.obs/string_alloc test to
test char8_t, too.
Differential Revision: https://reviews.llvm.org/D102360
Before this commit, we'd get a compilation error because the operator() overload was ambiguous.
Differential Revision: https://reviews.llvm.org/D102263
D85051's honeypot solution was a bit too aggressive swallowed up the
comparison types, which made comparing objects of different ordering
types ambiguous.
Depends on D101707.
Differential Revision: https://reviews.llvm.org/D101708
Don't use stat and lstat on Windows; lstat is missing, stat only provides
the modification times with second granularity (and does the wrong thing
regarding symlinks). Instead do a minimal reimplementation using the
native windows APIs.
Differential Revision: https://reviews.llvm.org/D101731
On Windows, the permission bits are mapped down to essentially only
two possible states; readonly or readwrite. Normalize the checked
permission bitmask to match what the implementation will return.
Differential Revision: https://reviews.llvm.org/D101728
For some reason clang-10 can't match the expected errors produced by
passing icomplete arrays to range access functions. Disabling the tests
is a stop-gap solution to fix the bots.
C++17 deprecates `std::raw_storage_iterator` and C++20 removes it.
Implements part of:
* P0174R2 'Deprecating Vestigial Library Parts in C++17'
* P0619R4 'Reviewing Deprecated Facilities of C++17 for C++20'
Differential Revision: https://reviews.llvm.org/D101730
* `operator!=` isn't in the spec
* `<compare>` is designed to work with `operator<=>` so it doesn't
really make sense to have `operator<=>`-less friendly sections.
Depends on D100283.
Differential Revision: https://reviews.llvm.org/D100342
Christopher Di Bella