This patch adds an implementation of __resize_default_init as
described in P1072R2. Additionally, it uses it in filesystem to
demonstrate its intended utility.
Once P1072 lands, or if it changes it's interface, I will adjust
the internal libc++ implementation to match.
llvm-svn: 347589
In r339743, I marked several aligned allocation tests as downright
unsupported on macosx in an attempt to unbreak the build. It turns
out that marking them as unuspported whenever we're on OS X is way
too coarse grained. This commit marks the tests as XFAIL with more
granularity.
llvm-svn: 347585
The test was marked as failing whenever the deployment target was 10.12
or older, but in reality the test passes when the deployment target is
10.12 on recent Clangs. This happens because only older clangs do not
honor the -faligned-allocation flag, which disables any availability
error related to aligned allocation support, regardless of the
deployment target.
llvm-svn: 347580
Summary:
In PR39232, we noticed that some variant tests started failing in C++2a mode
with recent Clangs, because the rules for literal types changed in C++2a. As
a result, a temporary fix was checked in (enabling the test only in C++17).
This commit is what I believe should be the long term fix: I removed the
tests that checked constexpr default-constructibility with a weird type
from the tests for index() and valueless_by_exception(), and instead I
added tests for those using an obviously literal type in the test for the
default constructor.
Reviewers: EricWF, mclow.lists
Subscribers: christof, jkorous, dexonsmith, arphaman, libcxx-commits, rsmith
Differential Revision: https://reviews.llvm.org/D54767
llvm-svn: 347568
This is a revert of r347421, except I'm using the with_system_cxx_lib
lit feature instead of availability to mark the test as unsupported
(because the problem is a bug in the dylib itself). In r347421, I said
I wasn't able to reproduce the issue and that's why I was removing it:
this was because I ran lit slightly wrong. The problem mentioned really
exists.
llvm-svn: 347475
The iterator types for different specializations of containers with the
same element type but different allocators are not required to be
convertible. This patch makes the test to take the iterator type from
the same container specialization as the created container.
Reviewed as https://reviews.llvm.org/D54806.
Thanks to Andrey Maksimov for the patch.
llvm-svn: 347423
I wasn't able to reproduce the issue referred to by the comment using
the libc++'s shipped with mac OS X 10.7 and 10.8, so I assume this may
have been fixed in a function that is now shipped in the headers. In
that case, the tests will pass no matter what dylib we're using.
In the worst case, some test bots will start failing and I'll understand
why I was wrong, and I can create an actual lit feature for it. Note
that I could just leave this test alone, but this change is on the path
towards eradicating vendor-specific availability markup from the test
suite.
llvm-svn: 347421
The XFAIL started passing since we're only testing for trivial-copyability of
reference_wrapper in C++14 and above. This commit constrains the XFAIL to
gcc-4.9 with C++14 (it would also fail on C++17 and above, but those standards
are not available with GCC 4.9).
llvm-svn: 347264
Some tests use type std::max_align_t, but don't include <cstddef> header
directly. As a result, these tests won't compile against some conformant
libraries.
Reviewed as https://reviews.llvm.org/D54645.
Thanks to Andrey Maksimov for the patch.
llvm-svn: 347232
A bunch of unordered containers tests call library functions but don't directly
include the corresponding header files:
- fabs() (defined in <cmath> which is not included);
- is_permutation() (defined in <algorithm> which is not included);
- next() (defined in <iterator> which is not included).
- As a result, these tests won't compile against some conformant libraries.
Reviewed as https://reviews.llvm.org/D54643.
Thanks to Andrey Maksimov for the patch.
llvm-svn: 347085
This was implicitly converting [1, 3] to bool, which triggers
an MSVC warning. The test should just pass `true`, which is
simpler, has the same behavior, and avoids the warning. (This
is a library test, not a compiler test, and the conversion happens
before calling `push_back`, so passing [1, 3] isn't interesting
in any way. This resembles a previous change to stop passing
`1 == 1` in the `vector<bool>` tests.)
llvm-svn: 346910
This patch renames the cxx-benchmark-unittests to check-cxx-benchmarks
and converts the target to use LIT in order to make the tests run faster
and provide better output.
In particular this runs each benchmark in a suite one by one, allowing
more parallelism while ensuring output isn't garbage with multiple threads.
Additionally, it adds the CMake flag '-DLIBCXX_BENCHMARK_TEST_ARGS=<list>'
to specify what options are passed when running the benchmarks.
llvm-svn: 346888
Summary:
P1006 adds support for constexpr in the specialization of pointer_traits
for raw pointers. This is necessary in order to use pointer_traits in
the upcoming constexpr containers. We expect P1006 to be voted into the
working draft for C++20 at the San Diego meeting.
Reviewers: mclow.lists, EricWF
Subscribers: christof, dexonsmith, libcxx-commits
Differential Revision: https://reviews.llvm.org/D53867
llvm-svn: 346764
This patch adds tests to ensure that multiset/unordered_multiset's emplace
method correctly constructs the elements without any intervening
constructions.
llvm-svn: 346743
Summary:
This fixes an regression when using bionic introduced in r345173.
I need to follow up and figure out what exactly is implied by
TEST_HAS_C11_FEATURES and see what the correct configuration is for
bionic (new versions should have everything the tests care about,
versions that predate C11 certainly don't), but this gets the tests
back to the old behavior.
Reviewers: EricWF
Reviewed By: EricWF
Subscribers: mclow.lists, christof, ldionne, libcxx-commits, cfe-commits
Differential Revision: https://reviews.llvm.org/D53956
llvm-svn: 345900
This reverts r345525. I'm reverting because that patch apparently caused
a regression on certain platforms (see https://reviews.llvm.org/D53994).
Since we don't fully understand the reasons for the regression, I'm
reverting until we can provide a fix we understand.
llvm-svn: 345893
This commit adds a merge member function to all the map and set containers,
which splices nodes from the source container. This completes support for
P0083r3.
Differential revision: https://reviews.llvm.org/D48896
llvm-svn: 345744
The types/comparators passed to std::upper_bound and std::lower_bound
are not required to provided to provide an operator</comp(...) which
accepts the arguments in reverse order. Nor are the ranges required
to have a strict weak ordering.
However, in debug mode we attempted to check the result of a comparison
with the arguments reversed, which may not compiler.
This patch removes the use of the debug comparator for upper_bound
and lower_bound.
equal_range et al still use debug comparators when they call
__upper_bound and __lower_bound.
See llvm.org/PR39458
llvm-svn: 345434
Summary:
C++14 sized deallocation is disabled by default due to ABI concerns. However, when a user manually enables it then libc++ should take advantage of it since sized deallocation can provide a significant performance win depending on the underlying malloc implementation. (Note that libc++'s definitions of sized delete don't do anything special yet, but users are free to provide their own).
This patch updates __libcpp_deallocate to selectively call sized operator delete when it's available. `__libcpp_deallocate_unsized` should be used when the size of the allocation is unknown.
On Apple this patch makes no attempt to determine if the sized operator delete is unavailable, only that the language feature is enabled. This could cause a compile error when using `std::allocator`, but the same compile error would occur whenever the user calls `new`, so I don't think it's a problem.
Reviewers: ldionne, mclow.lists
Reviewed By: ldionne
Subscribers: rsmith, ckennelly, libcxx-commits, christof
Differential Revision: https://reviews.llvm.org/D53120
llvm-svn: 345281
Summary:
C++14 sized deallocation is disabled by default due to ABI concerns. However, when a user manually enables it then libc++ should take advantage of it since sized deallocation can provide a significant performance win depending on the underlying malloc implementation. (Note that libc++'s definitions of sized delete don't do anything special yet, but users are free to provide their own).
This patch updates __libcpp_deallocate to selectively call sized operator delete when it's available. `__libcpp_deallocate_unsized` should be used when the size of the allocation is unknown.
On Apple this patch makes no attempt to determine if the sized operator delete is unavailable, only that the language feature is enabled. This could cause a compile error when using `std::allocator`, but the same compile error would occur whenever the user calls `new`, so I don't think it's a problem.
Reviewers: ldionne, mclow.lists
Reviewed By: ldionne
Subscribers: rsmith, ckennelly, libcxx-commits, christof
Differential Revision: https://reviews.llvm.org/D53120
llvm-svn: 345214
This reverts commits r333103 and r333108. _Float16 and __fp16 are C11
extensions and compilers other than Clang don't define these for C++.
Differential Revision: https://reviews.llvm.org/D53670
llvm-svn: 345199
Marshall Clow