- Quality-of-implementation: Avoid calling __unwrap_iter in constexpr contexts.
The user might conceivably write a contiguous iterator where normal iterator
arithmetic is constexpr-friendly but `std::to_address(it)` isn't.
- Bugfix: When you pass contiguous iterators to `std::copy`, you should get
back your contiguous iterator type, not a raw pointer. That means that
libc++ can't `__unwrap_iter` unless it also does `__rewrap_iter`.
Fortunately, this is implementable.
- Improve test coverage of the new `contiguous_iterator` test iterator.
This catches the bug described above.
- Tests: Stop testing that we can `std::copy` //into// an `input_iterator`.
Our test iterators may currently support that, but it seems nonsensical to me.
Differential Revision: https://reviews.llvm.org/D95983
- 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
After this patch, the only parts of P0879 that remain missing will be
std::nth_element, std::sort, and the heap/partial_sort algorithms.
Differential Revision: https://reviews.llvm.org/D93443
Zoe Carver says: "We decided that libc++ only supports C++20 constexpr algorithms
when `is_constant_evaluated` is also supported. Here's a link to the discussion."
https://reviews.llvm.org/D65721#inline-735682
Remove _LIBCPP_HAS_NO_BUILTIN_IS_CONSTANT_EVALUATED from tests, too.
See Louis's 5911e6a885 if needed to fix bots.
I've applied `UNSUPPORTED: clang-8` preemptively to the altered tests;
I don't know for sure that this was needed, because no clang-8 buildbots
are triggered on pull requests.
This patch makes `std::rotate` a constexpr. In doing so, this patch also
updates the internal `__move` and `__move_backward` funtions to be
constexpr.
This patch was previously reverted in ed653184ac because it was missing
some UNSUPPORTED markup for older compilers. This commit adds it.
Differential Revision: https://reviews.llvm.org/D65721
cppreference lists the support for this paper as partial.
I found 4 functions which the paper marks as `constexpr`,
but did not use the appropriate macro.
Differential Revision: https://reviews.llvm.org/D84275
This patch makes `std::rotate` a constexpr. In doing so, this patch also
updates the internal `__move` and `__move_backward` funtions to be
constexpr.
Reviewed By: ldionne
Differential Revision: https://reviews.llvm.org/D65721
There used to be a workaround where we'd pretend that GCC 5 didn't support
C++14 because it doesn't implement it properly. Since that workaround has
been removed (in 1eb211ada1), we need to mark a few individual tests as
failing with GCC 5.
C++98 and C++03 are effectively aliases as far as Clang is concerned.
As such, allowing both std=c++98 and std=c++03 as Lit parameters is
just slightly confusing, but provides no value. It's similar to allowing
both std=c++17 and std=c++1z, which we don't do.
This was discovered because we had an internal bot that ran the test
suite under both c++98 AND c++03 -- one of which is redundant.
Differential Revision: https://reviews.llvm.org/D80926
The testing script used to test libc++ historically did not like directories
without any testing files, so these tests had been added. Since this is
not necessary anymore, we can now remove these files. This has the benefit
that the total number of tests reflects the real number of tests more
closely, and we also skip some unnecessary work (especially relevant when
running tests over SSH).
However, some nothing_to_do.pass.cpp tests actually serve the purpose of
documenting that an area of the Standard doesn't need to be tested, or is
tested elsewhere. These files are not removed by this commit.
Removal done with:
import os
import itertools
for (dirpath, dirnames, filenames) in itertools.chain(os.walk('./libcxx/test'),
os.walk('./libcxxabi/test')):
if len(filenames + dirnames) > 1 and \
any(p == 'nothing_to_do.pass.cpp' for p in filenames):
os.remove(os.path.join(dirpath, 'nothing_to_do.pass.cpp'))
Summary:
In r342843, I added deprecation warnings to some facilities that were
deprectated in C++14 and C++17. However, those deprecation warnings
were not enabled by default.
After discussing this on IRC, we had finally gotten consensus to enable
those warnings by default, and I'm getting around to doing that only
now.
Reviewers: mclow.lists, EricWF
Subscribers: christof, jkorous, dexonsmith, jdoerfert, libcxx-commits
Differential Revision: https://reviews.llvm.org/D58140
llvm-svn: 355961
Summary:
Freestanding is *weird*. The standard allows it to differ in a bunch of odd
manners from regular C++, and the committee would like to improve that
situation. I'd like to make libc++ behave better with what freestanding should
be, so that it can be a tool we use in improving the standard. To do that we
need to try stuff out, both with "freestanding the language mode" and
"freestanding the library subset".
Let's start with the super basic: run the libc++ tests in freestanding, using
clang as the compiler, and see what works. The easiest hack to do this:
In utils/libcxx/test/config.py add:
self.cxx.compile_flags += ['-ffreestanding']
Run the tests and they all fail.
Why? Because in freestanding `main` isn't special. This "not special" property
has two effects: main doesn't get mangled, and main isn't allowed to omit its
`return` statement. The first means main gets mangled and the linker can't
create a valid executable for us to test. The second means we spew out warnings
(ew) and the compiler doesn't insert the `return` we omitted, and main just
falls of the end and does whatever undefined behavior (if you're luck, ud2
leading to non-zero return code).
Let's start my work with the basics. This patch changes all libc++ tests to
declare `main` as `int main(int, char**` so it mangles consistently (enabling us
to declare another `extern "C"` main for freestanding which calls the mangled
one), and adds `return 0;` to all places where it was missing. This touches 6124
files, and I apologize.
The former was done with The Magic Of Sed.
The later was done with a (not quite correct but decent) clang tool:
https://gist.github.com/jfbastien/793819ff360baa845483dde81170feed
This works for most tests, though I did have to adjust a few places when e.g.
the test runs with `-x c`, macros are used for main (such as for the filesystem
tests), etc.
Once this is in we can create a freestanding bot which will prevent further
regressions. After that, we can start the real work of supporting C++
freestanding fairly well in libc++.
<rdar://problem/47754795>
Reviewers: ldionne, mclow.lists, EricWF
Subscribers: christof, jkorous, dexonsmith, arphaman, miyuki, libcxx-commits
Differential Revision: https://reviews.llvm.org/D57624
llvm-svn: 353086
to reflect the new license. These used slightly different spellings that
defeated my regular expressions.
We understand that people may be surprised that we're moving the header
entirely to discuss the new license. We checked this carefully with the
Foundation's lawyer and we believe this is the correct approach.
Essentially, all code in the project is now made available by the LLVM
project under our new license, so you will see that the license headers
include that license only. Some of our contributors have contributed
code under our old license, and accordingly, we have retained a copy of
our old license notice in the top-level files in each project and
repository.
llvm-svn: 351648
test/std/algorithms/alg.modifying.operations/alg.generate/generate_n.pass.cpp
Silence MSVC warning C4244. This is expected when passing
floating-point values for size.
test/std/utilities/template.bitset/bitset.members/to_ullong.pass.cpp
test/std/utilities/template.bitset/bitset.members/to_ulong.pass.cpp
Avoid MSVC "warning C4293: '<<': shift count negative or too big,
undefined behavior". MSVC sees (1ULL << N) and warns - being guarded
by const bool canFit is insufficient. A small change to the code
avoids the warning without the need for a pragma.
Remove a spurious printf() declaration from to_ullong.pass.cpp.
Change ULL to UL in to_ulong.pass.cpp. The ULL suffix was
probably copy-pasted.
test/std/utilities/tuple/tuple.general/ignore.pass.cpp
Use LIBCPP_STATIC_ASSERT for consistency with other files.
test/support/container_test_types.h
Fix a null pointer dereference, found by MSVC /analyze
warning C6011 "Dereferencing NULL pointer 'm_expected_args'."
Fixes D41030.
llvm-svn: 320535
test/std/algorithms/alg.modifying.operations/alg.random.shuffle/random_shuffle_rand.pass.cpp
(Affects 64-bit architectures.) Include <cstddef> so we can take/return std::ptrdiff_t
(instead of int) in random_shuffle()'s RNG. (C++14 D.12 [depr.alg.random.shuffle]/2 says that
difference_type is used, and we're shuffling a plain array.)
test/std/algorithms/alg.sorting/alg.sort/sort/sort.pass.cpp
test/std/algorithms/alg.sorting/alg.sort/stable.sort/stable_sort.pass.cpp
(Affects 64-bit architectures.) Include <iterator> because we're already using iterator_traits.
Then, store the result of subtracting two RanIts as difference_type instead of long
(which truncates on LLP64 architectures like MSVC x64).
test/std/containers/sequences/forwardlist/forwardlist.ops/splice_after_flist.pass.cpp
test/std/containers/sequences/forwardlist/forwardlist.ops/splice_after_one.pass.cpp
(Affects 64-bit architectures.) Include <cstddef> so we can store the result of
subtracting two pointers as std::ptrdiff_t (instead of int).
test/std/input.output/iostream.format/input.streams/istream.unformatted/ignore_0xff.pass.cpp
(Affects 32-bit architectures.) Sometimes, size_t is too small. That's the case here,
where tellg() returns pos_type (N4606 27.7.2.3 [istream.unformatted]/39). Implementations can
have 64-bit pos_type (to handle large files) even when they have 32-bit size_t.
Fixes D27543.
llvm-svn: 289110
Add static_cast<int>. In these cases, the values are guaranteed to be small-ish,
and they're being compared to int elements.
test/std/containers/sequences/deque/deque.capacity/access.pass.cpp
Use int instead of unsigned to iterate from 0 to 10.
llvm-svn: 288747
Add static_cast<std::size_t> to more comparisons. (Performed manually, unlike part 8/12.)
Also, include <cstddef> when it wasn't already being included.
llvm-svn: 288746
sample() isn't specified with a reproducible algorithm, so expecting
exact output is non-Standard. Mark those tests with LIBCPP_ASSERT.
In test_small_population(), we're guaranteed to get all of the elements,
but not necessarily in their original order. When PopulationCategory is
forward, we're guaranteed stability (and can therefore test equal()).
Otherwise, we can only test is_permutation(). (As it happens, both libcxx
and MSVC's STL provide stability in this scenario for input-only iterators.)
llvm-svn: 287383
This patch implements the std::sample function added to C++17 from LFTS. It
also removes the std::experimental::sample implementation which now forwards
to std::sample.
llvm-svn: 279948
Libc++'s implementation of shuffle and sample already support lvalue and rvalue
RNG's. This patch adds tests for both categories and marks the issue as complete.
This patch also contains drive-by change for std::experimental::sample which
improves the diagnostics produced when the correct iterator categories are
not supplied.
llvm-svn: 279947
Summary:
The requirement on the `Size` type passed to *_n algorithms is that it is convertible to an integral type. This means we can't use a variable of type `Size` directly. Instead we need to convert it to an integral type first. The problem is finding out what integral type to convert it to. `__convert_to_integral` figures out what integral type to convert it to and performs the conversion, It also promotes the resulting integral type so that it is at least as big as an integer. `__convert_to_integral` also has a special case for converting enums. This should only work on non-scoped enumerations because it does not apply an explicit conversion from the enum to its underlying type.
Reviewers: chandlerc, mclow.lists
Reviewed By: mclow.lists
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D7449
llvm-svn: 228704
Louis Dionne