This PR addresses an undefined behavior that arises when using the
`std::fill` and `std::fill_n` algorithms, as well as their ranges
counterparts `ranges::fill` and `ranges::fill_n`, with `vector<bool, Alloc>`
that utilizes a custom-sized allocator with small integral types.
As a follow-up to #121013 (which focused on `std::ranges::copy`), this
PR optimizes the performance of `std::ranges::copy_backward` for
`vector<bool>::iterator`, addressing a subtask outlined in issue #64038.
The optimizations yield performance improvements of up to 2000x for
aligned copies and 60x for unaligned copies.
Implementing `constexpr std::stable_sort`. This is part of P2562R1,
tracked via issue #105360.
Closes#119394
Co-authored-by: A. Jiang <de34@live.cn>
Co-authored-by: Louis Dionne <ldionne.2@gmail.com>
This patch adds a large number of missing includes in the libc++ headers
and the test suite. Those were found as part of the effort to move
towards a mostly monolithic top-level std module.
Works towards P0619R4 / #99985.
The use of `std::get_temporary_buffer` and `std::return_temporary_buffer`
are replaced with `unique_ptr`-based RAII buffer holder.
Escape hatches:
- `_LIBCPP_ENABLE_CXX20_REMOVED_TEMPORARY_BUFFER` restores
`std::get_temporary_buffer` and `std::return_temporary_buffer`.
Drive-by changes:
- In `<syncstream>`, states that `get_temporary_buffer` is now removed,
because `<syncstream>` is added in C++20.
This patch hardens the "test iterators" we use to test algorithms by
ensuring that they don't get double-moved. As a result of this
hardening, the tests started reporting multiple failures where we would
double-move iterators, which are being fixed in this patch.
In particular:
- Fixed a double-move in pstl.partition
- Add coverage for begin()/end() in subrange tests
- Fix tests for ranges::ends_with and ranges::contains, which were
incorrectly calling begin() twice on the same subrange containing
non-copyable input iterators.
Fixes#100709
We were only checking that the comparator was rvalue callable,
when in reality the algorithms always call comparators as lvalues.
This patch also refactors the tests for callable requirements and
expands it to a few missing algorithms.
This is take 2 of #73451, which was reverted because it broke some
CI bots. The issue was that we checked __is_callable with arguments
in the wrong order inside std::upper_bound. This has now been fixed
and a test was added.
Fixes#69554
This reverts commit 8d151f804ff43aaed1edf810bb2a07607b8bba14, which
broke some build bots. I think that is caused by an invalid argument
order when checking __is_comparable in upper_bound.
We were only checking that the comparator was rvalue callable,
when in reality the algorithms always call comparators as lvalues.
This patch also refactors the tests for callable requirements and
expands it to a few missing algorithms.
Fixes#69554
In the tests I added for `ranges::find_last{_if{_not}}`, I accidentally
introduced an assumption that `same_as<array<T, 0>::iterator, T*>`; this
is a faulty assumption on MSVC-STL.
Fixes#100498.
Implements [P1223R5][] completely.
Includes an implementation of `find_last`, `find_last_if`, and
`find_last_if_not`.
[P1223R5]: https://wg21.link/p1223r5
One-sided binary search, aka meta binary search, has been in the public
domain for decades, and has the general advantage of being constant time
in the best case, with the downside of executing at most 2*log(N)
comparisons vs classic binary search's exact log(N). There are two
scenarios in which it really shines: the first one is when operating
over non-random-access iterators, because the classic algorithm requires
knowing the container's size upfront, which adds N iterator increments
to the complexity. The second one is when traversing the container in
order, trying to fast-forward to the next value: in that case the
classic algorithm requires at least O(N*log(N)) comparisons and, for
non-random-access iterators, O(N^2) iterator increments, whereas the
one-sided version will yield O(N) operations on both counts, with a
best-case of O(log(N)) comparisons which is very common in practice.
This patch contains a number of small portability improvements for the
test suite, making it easier to run the test suite with other standard
library implementations.
- Guard checks for _LIBCPP_HARDENING_MODE to avoid -Wundef
- Avoid defining _LIBCPP_HARDENING_MODE even when no hardening mode is
specified -- we should use the default mode of the library in that case.
- Add missing includes and qualify a few function calls.
- Avoid opening namespace std to forward declare stdlib containers. The
test suite should represent user code, and user code isn't allowed to do
that.
GCC 14 has been released a while ago. We've updated the CI to use GCC 14
now. This removes any old annotations in the tests and updates the
documentation to reflect the updated version requirements.
There were 7 occurrences of `UNSUPPORTED: !has-unix-headers`, versus 212
occurrences of `REQUIRES: has-unix-headers`.
I don't completely understand how libc++ uses UNSUPPORTED versus
REQUIRES, but it seems better to be consistent, and to avoid the double
negation in "this is unsupported if we don't have unix headers".
(This came to my attention because of the single occurrence in
`libcxx/test/std`. Our MSVC-internal test harness isn't aware of lit
features, so we teach it to skip tests via the incredibly primitive
method of searching for specific comments, so I had to deal with this
comment inconsistency.)
The return of malloc is implementation defined when the requested size
is 0. On platforms (such as AIX) that return a null pointer for 0 size,
operator new will throw a bad_alloc exception. operator new should
return a non null pointer for 0 size instead.
* Guard `std::__make_from_tuple_impl` tests with `#ifdef _LIBCPP_VERSION` and `LIBCPP_STATIC_ASSERT`.
* Change `_LIBCPP_CONSTEXPR_SINCE_CXX20` to `TEST_CONSTEXPR_CXX20`.
+ Other functions in `variant.swap/swap.pass.cpp` were already using the proper test macro.
* Mark `what` as `[[maybe_unused]]` when used by `TEST_LIBCPP_REQUIRE`.
+ This updates one occurrence in `libcxx/test/libcxx` for consistency.
* Windows `_putenv_s()` takes 2 arguments, not 3.
+ See MSVC documentation: https://learn.microsoft.com/en-us/cpp/c-runtime-library/reference/putenv-s-wputenv-s?view=msvc-170
+ POSIX `setenv()` takes `int overwrite`, but Windows `_putenv_s()` always overwrites.
* Avoid non-Standard zero-length arrays.
+ Followup to #74183 and #79792.
* Add `operator++()` to `unsized_it`.
+ The Standard requires this due to [N4981][] [move.iter.requirements]/1 "The template parameter `Iterator` shall
either meet the *Cpp17InputIterator* requirements ([input.iterators])
or model `input_iterator` ([iterator.concept.input])."
+ MSVC's STL requires this because it has a strengthened exception
specification in `move_iterator` that inspects the underlying iterator's
increment operator.
* `uniform_int_distribution` forbids `int8_t`/`uint8_t`.
+ See [N4981][] [rand.req.genl]/1.5. MSVC's STL enforces this.
+ Note that when changing the distribution's `IntType`, we need to be
careful to preserve the original value range of `[0, max_input]`.
* fstreams are constructible from `const fs::path::value_type*` on wide systems.
+ See [ifstream.cons], [ofstream.cons], [fstream.cons].
* In `msvc_stdlib_force_include.h`, map `_HAS_CXX23` to `TEST_STD_VER` 23 instead of 99.
+ On 2023-05-23, 71400505ca
started recognizing 23 as a distinct value.
* Fix test name typo: `destory_elements.pass.cpp` => `destroy_elements.pass.cpp`
[N4981]: https://wg21.link/N4981
There were various places where we incorrectly handled exceptions in the
PSTL. Typical issues were missing `noexcept` and taking iterators by
value instead of by reference.
This patch fixes those inconsistent and incorrect instances, and adds
proper tests for all of those. Note that the previous tests were often
incorrectly turned into no-ops by the compiler due to copy ellision,
which doesn't happen with these new tests.
Both `std::distance` or `ranges::distance` are inefficient for
non-sized ranges. Also, calculating the range using `int` type is
seriously problematic.
This patch avoids using `distance` and calculation of the length of
non-sized ranges.
Fixes#86833.
* Fix MSVC error C2466: cannot allocate an array of constant size 0
+ MSVC rejects this non-Standard extension. Previous fixes: #74183
* Fix MSVC warning C4805: `'=='`: unsafe mix of type `'int'` and type
`'const bool'` in operation
+ AFAICT, these lambdas were copy-pasted, and didn't intend to take and
return `int` here. This part of the test is using `vector<bool>` for
random-access but non-contiguous iterators, and it's checking how many
times the projection is invoked, but the projection doesn't need to do
anything squirrely, it should otherwise be an identity.
* Fix typos: "continuous" => "contiguous".
* `libcxx/test/std/algorithms/alg.nonmodifying/alg.find/find.pass.cpp`
emits a bunch of warnings, all caused by what appears to be intentional
code:
+ Silence MSVC warning C4245: conversion from `'int'` to `'wchar_t'`,
signed/unsigned mismatch
- Caused by: `test<U>(0, -1);`
+ Silence MSVC warning C4305: 'argument': truncation from `'int'` to
`'bool'`
- Caused by: `test<U>(0, -1);`
+ Silence MSVC warning C4310: cast truncates constant value
- Caused by: `test<U>(T(-129), U(-129));`
+ Silence MSVC warning C4805: `'=='`: unsafe mix of type `'char'` and
type `'bool'` in operation
- Caused by: `bool expect_match = val == to_find;`
*
`libcxx/test/std/algorithms/alg.nonmodifying/alg.fold/left_folds.pass.cpp`
+ Silence MSVC warning C4244: 'argument': conversion from `'double'` to
`'const int'`, possible loss of data
- Caused by `[](int const x, double const y) { return x + y; }`
deliberately being given `double`s to truncate.
*
`libcxx/test/std/numerics/numeric.ops/numeric.ops.midpoint/midpoint.pointer.pass.cpp`
+ Silence MSVC warnings about C++20 deprecated `volatile`.
- Caused by: `runtime_test< volatile T>();`
Previously there were two ways to override the verbose abort function
which gets called when a hardening assertion is triggered:
- compile-time: define the `_LIBCPP_VERBOSE_ABORT` macro;
- link-time: provide a definition of `__libcpp_verbose_abort` function.
This patch adds a new configure-time approach: the vendor can provide
a path to a custom header file which will get copied into the build by
CMake and included by the library. The header must provide a definition
of the
`_LIBCPP_ASSERTION_HANDLER` macro which is what will get called should
a hardening assertion fail. As of this patch, overriding
`_LIBCPP_VERBOSE_ABORT` will still work, but the previous mechanisms
will be effectively removed in a follow-up patch, making the
configure-time mechanism the sole way of overriding the default handler.
Note that `_LIBCPP_ASSERTION_HANDLER` only gets invoked when a hardening
assertion fails. It does not affect other cases where
`_LIBCPP_VERBOSE_ABORT` is currently used (e.g. when an exception is
thrown in the `-fno-exceptions` mode).
The library provides a default version of the custom header file that
will get used if it's not overridden by the vendor. That allows us to
always test the override mechanism and reduces the difference in
configuration between the pristine version of the library and
a platform-specific version.
Notable things in this commit:
* refactors `__indirect_binary_left_foldable`, making it slightly
different (but equivalent) to _`indirect-binary-left-foldable`_, which
improves readability (a [patch to the Working Paper][patch] was made)
* omits `__cpo` namespace, since it is not required for implementing
niebloids (a cleanup should happen in 2024)
* puts tests ensuring invocable robustness and dangling correctness
inside the correctness testing to ensure that the algorithms' results
are still correct
[patch]: https://github.com/cplusplus/draft/pull/6734
This patch removes assumptions that std::array's iterators are raw
pointers in the source code and in our test suite. While this is true
right now, this doesn't have to be true and ion the future we might want
to enable bounded iterators in std::array, which would require this
change.
This is a pre-requisite for landing #74482
This is the last PR that's needed (for now) to get libc++'s tests
working with MSVC's STL.
The ADDITIONAL_COMPILE_FLAGS machinery is very useful, but also very
problematic for MSVC, as it doesn't understand most of Clang's compiler
options. We've been dealing with this by simply marking anything that
uses ADDITIONAL_COMPILE_FLAGS as FAIL or SKIPPED, but that creates
significant gaps in test coverage.
Fortunately, ADDITIONAL_COMPILE_FLAGS also supports "features", which
can be slightly enhanced to send Clang-compatible and MSVC-compatible
options to the right compilers.
This patch adds the gcc-style-warnings and cl-style-warnings Lit features,
and uses that to pass the appropriate warning flags to tests. It also uses
TEST_MEOW_DIAGNOSTIC_IGNORED for a few local suppressions of MSVC
warnings.
Found while running libc++'s tests with MSVC's STL.
*
`libcxx/test/std/algorithms/alg.sorting/alg.heap.operations/sort.heap/ranges_sort_heap.pass.cpp`
+ Fix Clang `-Wunused-variable`, because `LIBCPP_ASSERT` expands to
nothing for MSVC's STL.
+ This is the same "always void-cast" change that #73437 applied to the
neighboring `complexity.pass.cpp`. I missed that
`ranges_sort_heap.pass.cpp` was also affected because we had disabled
this test.
*
`libcxx/test/std/input.output/file.streams/fstreams/ifstream.members/buffered_reads.pass.cpp`
*
`libcxx/test/std/input.output/file.streams/fstreams/ofstream.members/buffered_writes.pass.cpp`
+ Fix MSVC "warning C4244: '`=`': conversion from '`__int64`' to
'`_Ty`', possible loss of data".
+ This is a valid warning, possibly the best one that MSVC found in this
entire saga. We're accumulating a `std::vector<std::streamsize>` and
storing the result in `std::streamsize total_size` but we actually have
to start with `std::streamsize{0}` or we'll truncate.
*
`libcxx/test/std/input.output/filesystems/fs.enum/enum.path.format.pass.cpp`
+ Fix Clang `-Wunused-local-typedef` because the following usage is
libc++-only.
+ I'm just expanding it at the point of use, and using the dedicated
`LIBCPP_STATIC_ASSERT` to keep the line length down.
*
`libcxx/test/std/input.output/syncstream/syncbuf/syncstream.syncbuf.assign/swap.pass.cpp`
+ Fix MSVC "warning C4242: 'argument': conversion from '`int`' to
'`const _Elem`', possible loss of data".
+ This is a valid warning (possibly the second-best) as `sputc()`
returns `int_type`. If `sputc()` returns something unexpected, we want
to know, so we should separately say `expected.push_back(CharT('B'))`.
*
`libcxx/test/std/language.support/support.dynamic/new.delete/new.delete.single/new.size_align_nothrow.pass.cpp`
*
`libcxx/test/std/language.support/support.dynamic/new.delete/new.delete.single/new.size_nothrow.pass.cpp`
+ Fix MSVC "warning C6001: Using uninitialized memory '`x`'."
+ [N4964](https://wg21.link/N4964) \[new.delete.single\]/12:
> *Effects:* The deallocation functions
(\[basic.stc.dynamic.deallocation\]) called by a *delete-expression*
(\[expr.delete\]) to render the value of `ptr` invalid.
+ \[basic.stc.general\]/4:
> When the end of the duration of a region of storage is reached, the
values of all pointers representing the address of any part of that
region of storage become invalid pointer values (\[basic.compound\]).
Indirection through an invalid pointer value and passing an invalid
pointer value to a deallocation function have undefined behavior. Any
other use of an invalid pointer value has implementation-defined
behavior.
+ In certain configurations, after `delete x;` MSVC will consider `x` to
be radioactive (and in other configurations, it'll physically null out
`x` as a safety measure). We can copy it into `old_x` before deletion,
which the implementation finds acceptable.
*
`libcxx/test/std/ranges/range.adaptors/range.elements/general.pass.cpp`
*
`libcxx/test/std/ranges/range.adaptors/range.elements/iterator/deref.pass.cpp`
+ Fix MSVC "warning C4242: 'initializing': conversion from '`_Ty`' to
'`_Ty`', possible loss of data".
+ This was being emitted in `pair` and `tuple`'s perfect forwarding
constructors. Passing `short{1}` allows MSVC to see that no truncation
is happening.
*
`libcxx/test/std/ranges/range.adaptors/range.elements/iterator/member_types.compile.pass.cpp`
+ Fix MSVC "warning C4242: 'initializing': conversion from '`_Ty`' to
'`_Ty2`', possible loss of data".
+ Similarly, this was being emitted in `pair`'s perfect forwarding
constructor. After passing `short{1}`, I reduced repetition by relying
on CTAD. (I can undo that cleanup if it's stylistically undesirable.)
*
`libcxx/test/std/utilities/function.objects/refwrap/refwrap.const/type_conv_ctor.pass.cpp`
+ Fix MSVC "warning C4930: '`std::reference_wrapper<int> purr(void)`':
prototyped function not called (was a variable definition intended?)".
+ There's no reason for `purr()` to be locally declared (aside from
isolating it to a narrow scope, which has minimal benefits); it can be
declared like `meow()` above. 😸
*
`libcxx/test/std/utilities/memory/util.smartptr/util.smartptr.shared/util.smartptr.shared.create/make_shared_for_overwrite.pass.cpp`
*
`libcxx/test/std/utilities/smartptr/unique.ptr/unique.ptr.create/make_unique_for_overwrite.default_init.pass.cpp`
+ Fix MSVC static analysis warnings when replacing `operator new`:
```
warning C28196: The requirement that '(_Param_(1)>0)?(return!=0):(1)' is
not satisfied. (The expression does not evaluate to true.)
warning C6387: 'return' could be '0': this does not adhere to the
specification for the function 'new'.
warning C6011: Dereferencing NULL pointer 'reinterpret_cast<char
*>ptr+i'.
```
+ All we need is a null check, which appears in other `operator new`
replacements:
b85f1f9b18/libcxx/test/std/language.support/support.dynamic/new.delete/new.delete.single/new.size.replace.pass.cpp (L27-L28)
Found while running libc++'s tests with MSVC's STL.
*
`libcxx/test/std/algorithms/alg.modifying.operations/alg.unique/ranges_unique_copy.pass.cpp`
+ Fix MSVC "warning C4389: '`==`': signed/unsigned mismatch".
+ This was x86-specific for me. The LHS is `int` and the RHS is
`size_t`. We know the `array`'s size, so `static_cast<int>` is certainly
safe, and this matches the following `numberOfProj` comparisons.
*
`libcxx/test/std/containers/sequences/insert_range_sequence_containers.h`
+ Fix MSVC "warning C4267: 'argument': conversion from '`size_t`' to
'`const int`', possible loss of data".
+ `test_case.index` is `size_t`:
b85f1f9b18/libcxx/test/std/containers/insert_range_helpers.h (L65-L68)
+ But the container's `difference_type` is `int`:
b85f1f9b18/libcxx/test/support/test_allocator.h (L65-L76)
+ I introduced an alias `D` to make the long line more readable.
*
`libcxx/test/std/containers/unord/unord.map/eq.different_hash.pass.cpp`
*
`libcxx/test/std/containers/unord/unord.multimap/eq.different_hash.pass.cpp`
*
`libcxx/test/std/containers/unord/unord.multiset/eq.different_hash.pass.cpp`
*
`libcxx/test/std/containers/unord/unord.set/eq.different_hash.pass.cpp`
+ Fix MSVC "warning C6297: Arithmetic overflow. Results might not be an
expected value."
+ This warning is almost annoying enough to outright disable, but we use
similar `static_cast`s to deal with sign/truncation warnings elsewhere,
because there's some value in ensuring that product code is clean with
respect to these warnings. If there were many more occurrences, then
disabling the warning would be appropriate.
+ Cleanup: Change 2 inconsistently unqualified occurrences of `size_t`
to `std::size_t`.
*
`libcxx/test/std/containers/views/mdspan/layout_stride/index_operator.pass.cpp`
+ Fix MSVC "warning C4244: 'initializing': conversion from '`__int64`'
to '`size_t`', possible loss of data".
+ This was x86-specific for me. The `args` are indeed `int64_t`, and
we're storing the result in `size_t`, so we should cast.
* `libcxx/test/std/ranges/range.utility/range.utility.conv/container.h`
+ Fix MSVC "warning C4244: 'initializing': conversion from '`ptrdiff_t`'
to '`int`', possible loss of data".
+ Fix MSVC "warning C4267: 'initializing': conversion from '`size_t`' to
'`int`', possible loss of data".
+ We're initializing `int size_`, so we should explicitly cast from
pointer subtraction and `std::ranges::size`.
*
`libcxx/test/std/utilities/memory/util.smartptr/util.smartptr.shared/util.smartptr.shared.create/allocate_shared_for_overwrite.pass.cpp`
*
`libcxx/test/std/utilities/memory/util.smartptr/util.smartptr.shared/util.smartptr.shared.create/make_shared_for_overwrite.pass.cpp`
*
`libcxx/test/std/utilities/smartptr/unique.ptr/unique.ptr.create/make_unique_for_overwrite.default_init.pass.cpp`
+ Fix MSVC "warning C4309: 'initializing': truncation of constant
value".
+ MSVC emits this warning because `0xDE` is outside the range of `char`
(signed by default in our implementation).
* `libcxx/test/support/concat_macros.h`
+ Fix MSVC "warning C4244: 'argument': conversion from '`char16_t`' to
'`const char`', possible loss of data".
+ Fix MSVC "warning C4244: 'argument': conversion from '`unsigned int`'
to '`const char`', possible loss of data".
+ This code was very recently introduced by @mordante in #73395.
Found while running libc++'s tests with MSVC's STL.
`ranges::rotate_copy` takes `forward_iterator`s as this test's comment
banner correctly depicts. However, this test had bogus assertions
expecting that `ranges::rotate_copy` would be constrained away for
not-quite-**bidi** iterators. @philnik777 confirmed that these were
copy-paste relics from the `ranges::reverse_copy` test.
I fixed this by replacing the assertions with the test types that aren't
quite **forward** iterators/ranges. Additionally, I noticed that the
top-level `test()` function was missing coverage with the weakest
possible `forward_iterator<int*>`.
This revealed that the product code in `ranges_rotate_copy.h` was
similarly damaged. In addition to fixing it by taking `forward_iterator`
and `forward_range` as depicted in the Standard, this drops the
inclusion of `<__iterator/reverse_iterator.h>` as this algorithm doesn't
need `std::__reverse_range`.
Found while running libc++'s tests with MSVC's STL, where `std::array`
iterators are never pointers.
Most of these changes are reasonably self-explanatory (the `std::array`s
are right there, and the sometimes-slightly-wrapped raw pointer types
are a short distance away). A couple of changes are less obvious:
In `libcxx/test/std/containers/from_range_helpers.h`, `wrap_input()` is
called with `Iter` types that are constructible from raw pointers. It's
also sometimes called with an `array` as the `input`, so the first
overload was implicitly assuming that `array` iterators are pointers. We
can fix this assumption by providing a dedicated overload for `array`,
just like the one for `vector` immediately below. Finally,
`from_range_helpers.h` should explicitly include both `<array>` and
`<vector>`, even though they were apparently being dragged in already.
In `libcxx/test/std/containers/views/views.span/span.cons/iterator_sentinel.pass.cpp`,
fix `throw_operator_minus`. The error was pretty complicated, caused by
the concepts machinery noticing that `value_type` and `element_type`
were inconsistent. In the template instantiation context, you can see
the critical detail that `throw_operator_minus<std::_Array_iterator>` is
being formed.
Fortunately, the fix is extremely simple. To produce `element_type`
(which retains any cv-qualification, unlike `value_type`), we shouldn't
attempt to `remove_pointer` with the iterator type `It`. Instead, we've
already obtained the `reference` type, so we can `remove_reference_t`.
(This is modern code, where we have access to the alias templates, so I
saw no reason to use the older verbose form.)
Found while running libc++'s tests with MSVC's STL. This fixes 3 kinds of warnings:
- Add void-casts to fix `-Wunused-variable` warnings.
- Avoid sign/truncation warnings in `ConvertibleToIntegral.h`.
- Add `TEST_STD_AT_LEAST_23_OR_RUNTIME_EVALUATED` to avoid mixing preprocessor
and runtime tests.
- Cleanup: Add `TEST_STD_AT_LEAST_20_OR_RUNTIME_EVALUATED` for
consistency.
Дмитрий Изволов