Some tests require `TEST_WORKAROUND_CONSTEXPR_IMPLIES_NOEXCEPT`, but they
did not include the header that defines that macro.
Thanks to Michael Park for the patch.
Differential Revision: https://reviews.llvm.org/D62920
llvm-svn: 362660
This commit adds tests that repeated characters in regular expressions
are within numeric limits, and that a <= b in a regex like `x{a,b}`.
Thanks to Andrey Maksimov for the patch.
Differential Revision: https://reviews.llvm.org/D62816
llvm-svn: 362525
Summary:
This provides the `std::destroying_delete_t` declaration in C++2a and after. (Even when the compiler doesn't support the language feature).
However, the feature test macro `__cpp_lib_destroying_delete` is only defined when we have both language support and C++2a.
Reviewers: ldionne, ckennelly, serge-sans-paille, EricWF
Reviewed By: EricWF
Subscribers: dexonsmith, riccibruno, christof, jwakely, jdoerfert, mclow.lists, ldionne, libcxx-commits
Differential Revision: https://reviews.llvm.org/D55840
llvm-svn: 361572
Some tests assume that iteration through an unordered multiset elements
will return them in the same order as at the container creation. This
assumption is not true since the container is unordered, so that no
specific order of elements is ever guaranteed for such container. This
patch introduces checks verifying that any iteration will return
elements exactly from a set of valid values and without repetition,
but in no particular order.
Thanks to Andrey Maksimov for the patch.
Differential Revision: https://reviews.llvm.org/D56500
llvm-svn: 361494
Some tests assume that iteration through an unordered multimap elements
will return them in the same order as at the container creation. This
assumption is not true since the container is unordered, so that no
specific order of elements is ever guaranteed for such container. This
patch is a continuation of D54838 and introduces checks verifying that
any iteration will return elements exactly from a set of valid values
and without repetition, but in no particular order.
Thanks to Andrey Maksimov for the patch.
Differential Revision: https://reviews.llvm.org/D56498
llvm-svn: 361414
The `using namespace std;` opens us up to ambiguity
when any of the std:: names are also present in the global namespace.
Instead we should properly qualify names we use from std::.
llvm-svn: 361074
Use std::nextafter() instead of std::nexttoward() in midpoint tests.
In the context of this test, this should not cause any difference.
Since nexttowardl() is not implemented on NetBSD 8, the latter function
combined with 'long double' type caused test failure. nextafterl() does
not have this problem.
Differential Revision: https://reviews.llvm.org/D61748
llvm-svn: 360673
Drive-by:
* Fix potential race between check and update of `throw_one` in `operator new`
* Fix latent bug in `operator delete`, which shouldn't decrement `outstanding_new` when passed a null pointer
* Specifically catch the expected `bad_alloc` in `main` instead of `...`
Differential Revision: https://reviews.llvm.org/D50860
llvm-svn: 359827
Linux is failing even though the test runner does report this locale
is available, but the test still isn't expected to work on platforms
without the locale (like Android).
llvm-svn: 359726
This adds explicit support for the WASI platform to libcxx.
WASI libc uses some components from musl, however it's not fully compatible
with musl, so we're planning to stop using _LIBCPP_HAS_MUSL_LIBC and
customize for WASI libc specifically.
Differential Revision: https://reviews.llvm.org/D61336
Reviewers: sbc100, ldionne
llvm-svn: 359703
Summary:
The current implementation of aligned storage was written before we had `alignas`, so it used a list of builtin types to force the alignment. But this doesn't work overaligned requests.
This patch adds a fallback case supporting over-alignment. It only affects case that were previously ill-formed.
Reviewers: rsmith, ldionne, dlj, mclow.lists
Reviewed By: mclow.lists
Subscribers: mclow.lists, dexonsmith, libcxx-commits
Differential Revision: https://reviews.llvm.org/D61301
llvm-svn: 359596
The standard requires the following for the std::regex_constants::error_type
values: "The type error_type is an implementation-defined enumerated type."
The values of this enumerated type are not required to be non-zero.
This patch makes such checks in tests libc++-specific to let the tests
pass for other conforming implementations.
Thanks to Andrey Maksimov for the patch.
Differential Revision: https://reviews.llvm.org/D61195
llvm-svn: 359320
When the arguments to tuple cat were const, the const was incorrectly
propagated into the type of the resulting tuple. For example:
const std::tuple<int> t(42);
auto r = std::tuple_cat(t, t);
// Incorrect! should be std::tuple<int, int>.
static_assert(is_same_v<decltype(r), std::tuple<const int, const int>>);
llvm-svn: 359255
All constant expressions are non-potentially-throwing in C++14, but that is *not* the case in C++17. Change these tests of the `variant`-flavored overloads of `std::get` to expect the correct behavior when the compiler is not GCC or is GCC 9+.
Credit to Jonathan Wakely for providing an improved version of my initial change that validates the incorrect behavior on GCC < 9 as well as validating the correct behavior on other compilers.
Differential Revision: https://reviews.llvm.org/D61033
llvm-svn: 359220
Teach libcxx to stop using various deprecated __has_* type traits, in favor of
the ("modern", C++11 era) __is_* type traits.
This is mostly just a simplification, but fixes at least one bug: _Atomic T
should be considered trivially-destructible, but is not considered to be POD by
Clang, and __has_trivial_destructor is specified in the GCC documentation as
returning false for non-POD non-class types.
Differential Revision: https://reviews.llvm.org/D48292
llvm-svn: 359159
Summary:
All overloads of `::abs` and `std::abs` must be present in both `<cmath>` and `<cstdlib>`. This is problematic to implement because C defines `fabs` in `math.h` and `labs` in `stdlib.h`. This introduces a circular dependency between the two headers.
This patch implements that requirement by moving `abs` into `math.h` and making `stdlib.h` include `math.h`. In order to get the underlying C declarations from the "real" `stdlib.h` inside our `math.h` we need some trickery. Specifically we need to make `stdlib.h` include next itself.
Suggestions for a cleaner implementation are welcome.
Reviewers: mclow.lists, ldionne
Reviewed By: ldionne
Subscribers: krytarowski, fedor.sergeev, dexonsmith, jdoerfert, jsji, libcxx-commits
Differential Revision: https://reviews.llvm.org/D60097
llvm-svn: 359020
Due to MSVC's decision to encode `wchar_t` as UTF-16, it rejects wide
character/string literals that expect a character value greater than
`\xffff`. UTF-16 `wchar_t` is clearly non-conforming, given that the
standard requires wchar_t to be capable of representing all characters
in the supported wide character execution sets, but rejecting e.g.
`\x40003` is a reasonably sane compromise given that encoding choice:
there's an expectation that `\xFOO` produces a single character in the
resulting literal. Consequently `L'\x40003'`/`L"\x40003"` are ill-formed
literals on MSVC. `L'\U00040003'` is a high surrogate (and produces a
warning about ignoring the "second character" in a multi-character
literal), and `L"\U00040003"` is a perfectly-valid `const wchar_t[3]`.
This change updates these tests to use universal-character-names instead
of raw values for the intended character values, which technically makes
them portable even to implementations that don't use a unicode
transformation format encoding for their wide character execution
character set. The two-character literal `L"\u1005e"` is awkward - the
`e` looks like part of the UCN's hex encoding - but necessary to compile
in '03 mode since '03 didn't allow UCNs to be used for members of the
basic execution character set even in character/string literals.
I've also eliminated the extraneous `\x00` "bonus null-terminator" in
some of the string literals which doesn't affect the tested behavior.
I'm sorry about using `*L"\U00040003"` in `conversions.string/to_bytes.pass.cpp`,
but it's correct for platforms with 32-bit wchar_t, *and* doesn't
trigger narrowing warnings as did the prior `CharT(0x40003)`.
Differential Revision: https://reviews.llvm.org/D60950
llvm-svn: 358908
This is a followup to [1] which added a new `__debug_less::operator()` overload.
[2] added `_LIBCPP_CONSTEXPR_AFTER_CXX17` to the original
`__debug_less::operator()` between the time of writing [1] and landing it. This
change adds `_LIBCPP_CONSTEXPR_AFTER_CXX17` to the new overload too.
[1] https://reviews.llvm.org/rL358423
[2] https://reviews.llvm.org/rL358252
Differential Revision: https://reviews.llvm.org/D60724
llvm-svn: 358725
In r358591, I added a test that uses the debug database from multiple
threads and that helped us uncover the problem that was fixed in r355367.
However, the test broke the tsan CI bots, and I think the problem is the
test allocator that was used in the test (which is not thread safe).
I'm committing again without using the test allocator, and in a separate
test file.
llvm-svn: 358610
This reverts r358591, which seems to have uncovered an actual bug and
causes the tsan CI to fail. We need to fix the bug and re-commit the
test.
llvm-svn: 358593
There are many STL algorithms (such as lexicographical_compare) that compare
values pointed to by iterators like so:
__comp(*it1, *it2);
When building with `_LIBCPP_DEBUG=0`, comparators are wrapped in `__debug_less`
which does some additional validation. But `__debug_less::operator()` takes
non-const references, so if the type of `*it1` is int, not int&, then the build
will fail.
This change adds a `const&` overload for `operator()` to fix the build.
Differential Revision: https://reviews.llvm.org/D60592
llvm-svn: 358423
We used to do it against the current system's libc++abi, which is not as
good as doing it with the libc++abi that matches the libc++ we're running
against.
Note that I made sure we were indeed picking up the provided libc++abi
by replacing it by something that doesn't work and watching it burn.
llvm-svn: 358294
Summary:
In r348529, I improved the library-defined diagnostic for using containers
with a non-const comparator/hasher. However, the check is now performed
too early, which leads to the diagnostic being emitted in cases where it
shouldn't. See PR41360 for details.
This patch moves the diagnostic to the destructor of the containers, which
means that the diagnostic will only be emitted when the container is instantiated
at a point where the comparator and the key/value are required to be complete.
We still retain better diagnostics than before r348529, because the diagnostics
are performed in the containers themselves instead of __tree and __hash_table.
As a drive-by fix, I improved the diagnostic to mention that we can't find
a _viable_ const call operator, as suggested by EricWF in PR41360.
Reviewers: EricWF, mclow.lists
Subscribers: christof, jkorous, dexonsmith, libcxx-commits, zoecarver
Tags: #libc
Differential Revision: https://reviews.llvm.org/D60540
llvm-svn: 358189
We fixed incorrect behavior of input streams in r357775 and tests were
added accordingly. However, older versions of macOS don't have the
change in the dylib yet, so the tests fail on those platforms.
llvm-svn: 357794
Summary:
This is a re-application of r357533 and r357531. They had been reverted
because we thought the commits broke the LLDB data formatters, but it
turns out this was because only r357531 had been included in the CI
run.
Before this patch, we would only ever throw an exception if the badbit
was set on the stream. The Standard is currently very unclear on how
exceptions should be propagated and what error flags should be set by
the input stream operations. This commit changes libc++ to behave under
a different (but valid) interpretation of the Standard. This interpretation
of the Standard matches what other implementations are doing.
This effectively implements the wording in p1264r0. It hasn't been voted
into the Standard yet, however there is wide agreement that the fix is
correct and it's just a matter of time before the fix is standardized.
PR21586
PR15949
rdar://problem/15347558
Reviewers: mclow.lists, EricWF
Subscribers: christof, dexonsmith, cfe-commits
Differential Revision: https://reviews.llvm.org/D49863
llvm-svn: 357775
This builds on the work done in r342808 and adds _LIBCPP_NODISCARD_EXT
to 37 more functions, namely:
adjacent_find, all_of, any_of, binary_search, clamp, count_if, count,
equal_range, equal, find_end, find_first_not_of, find_first_of, find_if,
find, includes, is_heap_until, is_heap, is_partitioned, is_permutation,
is_sorted_until, is_sorted, lexicographical_compare, lower_bound,
max_element, max, min_element, min, minmax_element, minmax, mismatch,
none_of, remove_if, remove, search_n, search, unique, upper_bound
The motivation here is that we noticed that find_if is nodiscard with
Visual Studio's standard library, and we deemed that useful
(https://crbug.com/948122).
https://devblogs.microsoft.com/cppblog/c17-progress-in-vs-2017-15-5-and-15-6/
says "Our criteria for emitting the warning are: discarding the return
value is a guaranteed leak [...], discarding the return value is
near-guaranteed to be incorrect (e.g. remove()/remove_if()/unique()), or
the function is essentially a pure observer (e.g. vector::empty() and
std::is_sorted())." so I went through algorithm and tried to apply these
criteria.
Some of these, like vector::empty() are already nodiscard per C++
standard and didn't need changing.
I didn't (yet?) go over std::string::find* methods which should probably
have _LIBCPP_NODISCARD_EXT too (but not as part of this change).
Differential Revision: https://reviews.llvm.org/D60145
llvm-svn: 357619
Summary:
Otherwise, std::is_pointer<id __strong> works, but std::is_pointer<id __weak>
(and others) don't work as expected.
The previous patch (r357517) had to be reverted in r357569 because it
broke the Chromium build. This patch shouldn't have the same problem.
rdar://problem/49126333
Reviewers: ahatanak, EricWF
Subscribers: christof, jkorous, dexonsmith, libcxx-commits
Differential Revision: https://reviews.llvm.org/D60087
llvm-svn: 357586
Fixed the inability to properly rebind the testing allocator, by making the
inner alloc_impl type a plain struct and making the operations templates. Before
rebind failed to compile complaining that a alloc_impl<T>* was not convertible
to an alloc_impl<U>*.
This enables the test to pass for MSVC++ once we provide the strong guarantee
for the copy assignment operator.
Reviewed as https://reviews.llvm.org/D60023
llvm-svn: 357545
This reverts commits r357533 and r357531, which broke the LLDB
data formatters. I'll hold off until we know how to fix the data
formatters accordingly.
llvm-svn: 357536
Summary:
Before this patch, we would only ever throw an exception if the badbit
was set on the stream. The Standard is currently very unclear on how
exceptions should be propagated and what error flags should be set by
the input stream operations. This commit changes libc++ to behave under
a different (but valid) interpretation of the Standard. This interpretation
of the Standard matches what other implementations are doing.
I will submit a paper in San Diego to clarify the Standard such that the
interpretation used in this commit (and other implementations) is the only
possible one.
PR21586
PR15949
rdar://problem/15347558
Reviewers: mclow.lists, EricWF
Subscribers: christof, dexonsmith, cfe-commits
Differential Revision: https://reviews.llvm.org/D49863
llvm-svn: 357531
The current definitions were entirely broken. They didn't call any
existing constructor and the forgot to friend the expression types they
were trying to construct.
llvm-svn: 357453
Summary: Completes P0357R3, which was merged into the C++20 Working Draft in San Diego.
Reviewers: EricWF, mclow.lists
Subscribers: christof, jkorous, dexonsmith, libcxx-commits
Differential Revision: https://reviews.llvm.org/D54722
llvm-svn: 357423
Summary:
Currently the C++03 implementation of common_type has much different behavior than the C++11 one. This causes bugs, including inside `<chrono>`.
This patch unifies the two implementations as best it can. The more code they share, the less their behavior can diverge.
Reviewers: mclow.lists, ldionne, sbenza
Reviewed By: mclow.lists, ldionne
Subscribers: libcxx-commits
Tags: #libc
Differential Revision: https://reviews.llvm.org/D59678
llvm-svn: 357370
Some tests #include <iostream> but they don't use anything from the
header. Those are probably artifacts of when the tests were developped.
llvm-svn: 357181
Dylib support for shared_mutex was added in macOS 10.12, so the tests
should be XFAILed accordingly instead of being completely disabled
whenever availability is enabled.
rdar://problem/48769104
llvm-svn: 357079
Summary:
Adds the coroutine `std::experimental::task<T>` type described in proposal P1056R0.
See https://wg21.link/P1056R0.
This implementation allows customization of the allocator used to allocate the
coroutine frame by passing std::allocator_arg as the first argument, followed by
the allocator to use.
This supports co_awaiting the same task multiple times. The second and
subsequent times it returns a reference to the already-computed value.
This diff also adds some implementations of other utilities that have potential for
standardization as helpers within the test/... area:
- `sync_wait(awaitable)` - See P1171R0
- `manual_reset_event`
Move the definition of the __aligned_allocation_size helper function
from <experimental/memory_resource> to <experimental/__memory>
so it can be more widely used without pulling in memory_resource.
Outstanding work:
- Use C++14 keywords directly rather than macro versions
eg. use `noexcept` instead of `_NOEXCEPT`).
- Add support for overaligned coroutine frames.
This may need wording in the Coroutines TS to support passing the extra `std::align_val_t`.
- Eliminate use of `if constexpr` if we want it to compile under C++14.
Patch by @lewissbaker (Lewis Baker).
llvm-svn: 357010
Summary: Filesystem doesn't work on Windows, so we need a mechanism to turn it off for the time being.
Reviewers: ldionne, serge-sans-paille, EricWF
Reviewed By: EricWF
Subscribers: mstorsjo, mgorny, christof, jdoerfert, libcxx-commits
Differential Revision: https://reviews.llvm.org/D59619
llvm-svn: 356633
Summary:
Also add the corresponding XFAILs to tests that require filesystem.
The approach taken to mark <filesystem> as unavailable in this patch
is to mark all the header as unavailable using #pragma clang attribute.
Marking each declaration using the attribute is more intrusive and
does not provide a lot of value right now because pretty much everything
in <filesystem> requires dylib support, often transitively.
This is an alternative to https://reviews.llvm.org/D59093.
A similar (but partial) patch was already applied in r356558.
Reviewers: mclow.lists, EricWF, serge-sans-paille
Subscribers: christof, jkorous, dexonsmith, libcxx-commits
Differential Revision: https://reviews.llvm.org/D59224
llvm-svn: 356616
This fixes CI for back-deployment testers on platforms that don't have
<filesystem> support in the dylib.
This is effectively half of https://reviews.llvm.org/D59224. The other
half requires fixes in Clang.
llvm-svn: 356558
Louis Dionne