Jobs that test with a more recent standard version run more tests, so
they take longer. We'll decrease the average latency by running them
first instead of last.
And remove the dedicated debug-iterator tests; we want to test this in all modes.
We have a CI step for testing the whole test suite with `--debug_level=1` now.
Part of https://reviews.llvm.org/D102003
And remove the dedicated debug-iterator test; we want to test this in all modes.
We have a CI step for testing the whole test suite with `--debug_level=1` now.
Part of https://reviews.llvm.org/D102003
This is a rough reapplication of the change that fixed std::to_address
to avoid relying on element_type (da456167). It is somewhat different
because the fix to avoid breaking Clang (which caused it to be reverted
in 347f69c55) was a bit more involved.
Differential Revision: https://reviews.llvm.org/D101638
This simply applies Howard's commit 4c80bfbd53 consistently
across all the associative and unordered container tests.
"unord.set/insert_hint_const_lvalue.pass.cpp" failed with `-D_LIBCPP_DEBUG=1`
before this patch; it was the only one that incorrectly reused
invalid iterator `e`. The others already used valid iterators
(generally `c.end()`); I'm just making them all match the same pattern
of usage: "e, then r, then c.end() for the rest."
Differential Revision: https://reviews.llvm.org/D101679
`__debug_less` ends up running the comparator up-to-twice per comparison,
because whenever `(x < y)` it goes on to verify that `!(y < x)`.
This breaks the strict "Complexity" guarantees of algorithms like
`inplace_merge`, which we test in the test suite. So, just skip the
complexity assertions in debug mode.
Differential Revision: https://reviews.llvm.org/D101677
The range of char pointers [data, data+size] is a valid closed range,
but the range [begin, end) is valid only half-open.
Differential Revision: https://reviews.llvm.org/D101676
This appears to be a bug in our string::assign: when assigning into
a longer string, from a shorter snippet of itself, we invalidate
iterators before doing the copy. We should invalidate them afterward.
Also drive-by improve the formatting of a function header.
Differential Revision: https://reviews.llvm.org/D101675
This allocator is not intended for libc++'s users to use;
it's strictly an implementation detail of `src/locale.cpp`.
So, move it to the `src/include/` directory.
Drive-by const-qualify its comparison operators.
For consistency with `__hidden_allocator` (defined in `src/thread.cpp`),
do *not* remove it from "libcxx/lib/libc++unexp.exp",
"libcxx/utils/symcheck-blacklists/linux_blacklist.txt", etc.
Differential Revision: https://reviews.llvm.org/D101293
On Windows, static vs DLL linking affects details in quite a few
cases, so it's good to have coverage for both cases.
Testing with static linking also increases coverage for a number of
cases and individual checks that have had to be waived for the DLL
case, and allows testing libc++experimental, increasing the number
of test cases actually executed by 180 (176 new tests from
libc++experimental and 4 ones that are XFAIL windows-dll).
Also drop the "generic-" prefix from these configuration names, as
they're perhaps not what the "generic" prefix intended originally
in the other generic-posix configurations.
Differential Revision: https://reviews.llvm.org/D101565
This reverts commit da456167, which broke the Clang build. I'm able to
reproduce it but I want to give myself a bit more time to investigate.
Differential Revision: https://reviews.llvm.org/D101638
In std::tuple, we should try to avoid calling std::is_copy_constructible
whenever we can to avoid surprising interactions with (I believe) compiler
builtins. This bug was reported in https://reviews.llvm.org/D96523#2730953.
The issue was that when tuple<_Up...> was the same as tuple<_Tp...>, we
would short-circuit the _Or (because sizeof...(_Tp) != 1) and go evaluate
the following `is_constructible<_Tp, const _Up&>...`. That shouldn't
actually be a problem, but see the analysis in https://reviews.llvm.org/D101770#2736470
for why it is with Clang and GCC.
Instead, after this patch, we check whether the constructed-from tuple
is the same as the current tuple regardless of the number of elements,
since we should always prefer the normal copy constructor in that case
anyway.
Differential Revision: https://reviews.llvm.org/D101770
This makes the libc++ tests more portable -- almost all of them should
now work on Windows, except for some tests that assume a shell is
available on the target. We should probably provide a way to exclude
those anyway for the purpose of running tests on embedded targets.
Differential Revision: https://reviews.llvm.org/D89495
This fixes the issue by implementing _And using the short-circuiting
SFINAE trick that we previously used only in std::tuple. One thing we
could look into is use the naive recursive implementation for disjunctions
with a small number of arguments, and use that trick with larger numbers
of arguments. It might be the case that the constant overhead for setting
up the SFINAE trick makes it only worth doing for larger packs, but that's
left for further work.
This problem was raised in https://reviews.llvm.org/D96523.
Differential Revision: https://reviews.llvm.org/D101661
This patch gets rid of technical debt around std::pointer_safety which,
I claim, is entirely unnecessary. I don't think anybody has used
std::pointer_safety in actual code because we do not implement the
underlying garbage collection support. In fact, P2186 even proposes
removing these facilities entirely from a future C++ version. As such,
I think it's entirely fine to get rid of complex workarounds whose goals
were to avoid breaking the ABI back in 2017.
I'm putting this up both to get reviews and to discuss this proposal for
a breaking change. I think we should be comfortable with making these
tiny breaks if we are confident they won't hurt anyone, which I'm fairly
confident is the case here.
Differential Revision: https://reviews.llvm.org/D100410
`test/std/ranges/range.access/range.access.cbegin/incomplete.compile.verify.cpp`
was accidentally copied (and apparently the author either forgot to
delete it or forgot to commit the deletion).
TEST=`ninja cxx && ninja check-cxx` locally
C++20 revised the definition of what it means to be an iterator. While
all _Cpp17InputIterators_ satisfy `std::input_iterator`, the reverse
isn't true. D100271 introduces a new test adaptor to accommodate this
new definition (`cpp20_input_iterator`).
In order to help readers immediately distinguish which input iterator
adaptor is _Cpp17InputIterator_, the current `input_iterator` adaptor
has been prefixed with `cpp17_`.
Differential Revision: https://reviews.llvm.org/D101242
This reverts one of the macros just added in D101613, because it turns out
that the <utility> header actually uses the identifiers __x, __y, __z.
We probably *shouldn't* use __z if it's reserved on Windows; but since
it's not causing us any active problem even on Windows, I think this is
the safest way to unbreak the test.
This reverts a224bf8ec4 and fixes the
underlying issue.
The underlying issue is simply that MSVC headers contains a define
like "#define __in", where __in is one macro in the MSVC Source
Code Annotation Language, defined in sal.h
Just use a different variable name than "__in"
__indirectly_readable_impl, and add "__in" to nasty_macros.h just
like the existing __out. (Also adding a couple more potentially
conflicting ones.)
Differential Revision: https://reviews.llvm.org/D101613
If libc++ is built as a DLL, calls to operator new within the DLL aren't
overridden if a user provides their own operator in calling code.
Therefore, the alloc counter doesn't pick up on allocations done within
std::string, so skip that check if running on windows. (Technically,
we could keep the checks if running on windows when not built as a DLL,
but trying to keep the conditionals simple.)
Differential Revision: https://reviews.llvm.org/D100219
A span has no idea what container (if any) "owns" its iterators, nor
under what circumstances they might become invalidated.
However, continue to use `__wrap_iter<T*>` instead of raw `T*` outside
of debug mode, because we've been shipping `std::span` since Clang 7
and ldionne doesn't want to break ABI. (Namely, the mangling of functions
taking `span::iterator` as a parameter.) Permit using raw `T*` there,
but only under an ABI macro: `_LIBCPP_ABI_SPAN_POINTER_ITERATORS`.
Differential Revision: https://reviews.llvm.org/D101003
To run llvm-lit manually from the command line:
./bin/llvm-lit -sv --param std=c++2b --param cxx_under_test=`pwd`/bin/clang \
--param debug_level=1 ../libcxx/test/
Tests that currently fail with `debug_level=1` are marked `LIBCXX-DEBUG-FIXME`,
but my intent is to deal with all of them and leave no such annotations in
the codebase within the next couple weeks. (I have patches for all of them
in my local checkout.)
Differential Revision: https://reviews.llvm.org/D100866
This line was confusing some people: it's not supposed to indicate
any kind of problem with the script, and I can't see any way it could
even help with troubleshooting. So, just silence it.
* `std::ranges::range`
* `std::ranges::sentinel_t`
* `std::ranges::range_difference_t`
* `std::ranges::range_value_t`
* `std::ranges::range_reference_t`
* `std::ranges::range_rvalue_reference_t`
* `std::ranges::common_range`
`range_size_t` depends on `sized_range` and will be added alongside it.
Implements parts of:
* P0896R4 The One Ranges Proposal`
Depends on D100255.
Differential Revision: https://reviews.llvm.org/D100269
Louis Dionne