Summary:
std::tuple marks its constructors as noexcept when the corresponding
memberwise constructors are noexcept too -- this commit improves std::pair
so that it behaves the same.
This is a re-application of r348824, which broke the build in C++03 mode
because a test was marked as supported in C++03 when it shouldn't be.
Note:
I did not add support in the explicit and non-explicit `pair(_Tuple&& __p)`
constructors because those are non-standard extensions, and supporting them
properly is tedious (we have to copy the rvalue-referenceness of the deduced
_Tuple&& onto the result of tuple_element).
<rdar://problem/29537079>
Reviewers: mclow.lists, EricWF
Subscribers: christof, llvm-commits
Differential Revision: https://reviews.llvm.org/D48669
llvm-svn: 348847
Summary:
std::tuple marks its constructors as noexcept when the corresponding
memberwise constructors are noexcept too -- this commit improves std::pair
so that it behaves the same.
Note:
I did not add support in the explicit and non-explicit `pair(_Tuple&& __p)`
constructors because those are non-standard extensions, and supporting them
properly is tedious (we have to copy the rvalue-referenceness of the deduced
_Tuple&& onto the result of tuple_element).
<rdar://problem/29537079>
Reviewers: mclow.lists, EricWF
Subscribers: christof, llvm-commits
Differential Revision: https://reviews.llvm.org/D48669
llvm-svn: 348824
The tests were marked to fail based on the 'availability' LIT feature.
However, those tests should really only be failing when we run them
against the dylibs that were deployed on macosx10.7 and macosx10.8,
which the deployment target has nothing to do with.
This caused the tests to unexpectedly pass when running the tests
with deployment target macosx10.{7,8} but running with a recent dylib.
llvm-svn: 348520
The standard section [array.zero] requires the return value of begin()
and end() methods of a zero-sized array to be unique. Eric Fiselier
clarifies: "That unique value cannot be null, and must be properly aligned".
This patch adds checks for the first part of this clarification: unique
value returned by these methods cannot be null.
Reviewed as https://reviews.llvm.org/D55366.
Thanks to Andrey Maksimov for the patch.
llvm-svn: 348509
The section array.zero says: "The return value of data() is unspecified".
This patch marks all checks of the array<T, 0>.data() return value as
libc++ specific.
Reviewed as https://reviews.llvm.org/D55364.
Thanks to Andrey Maksimov for the patch.
llvm-svn: 348485
Whether an explicit instantiation declaration should be provided is not
a matter of availability markup.
This problem is exemplified by the fact that some tests were incorrectly
marked as XFAIL when they should instead have been using the definition
of streams from the headers, and hence passing, and that, regardless of
whether visibility annotations are enabled.
llvm-svn: 348436
Summary:
This was voted into C++20 in San Diego. Note that there was a revision
D0318R2 which did include unwrap_reference_t, but we mistakingly voted
P0318R1 into the C++20 Working Draft (which does not include
unwrap_reference_t). This patch implements D0318R2, which is what
we'll end up with in the Working Draft once this mistake has been
fixed.
Reviewers: EricWF, mclow.lists
Subscribers: christof, dexonsmith, libcxx-commits
Differential Revision: https://reviews.llvm.org/D54485
llvm-svn: 348138
The test was previously marked as unsupported on all Apple platforms, when
we really just want to mark it as unsupported for previously shipped dylibs
on macosx.
llvm-svn: 347920
This reverts commit 087f065cb0c7463f521a62599884493aaee2ea12.
The tests were failing on 32 bit builds, and I don't have time
to clean them up right now. I'll recommit tomorrow with fixed tests.
llvm-svn: 347816
Summary:
Starting in Clang 8.0 and GCC 8.0, `alignof` and `__alignof` return different values in same cases. Specifically `alignof` and `_Alignof` return the minimum alignment for a type, where as `__alignof` returns the preferred alignment. libc++ currently uses `__alignof` but means to use `alignof`. See llvm.org/PR39713
This patch introduces the macro `_LIBCPP_ALIGNOF` so we can control which spelling gets used.
This patch does not introduce any ABI guard to provide the old behavior with newer compilers. However, if we decide that is needed, this patch makes it trivial to implement.
I think we should commit this change immediately, and decide what we want to do about the ABI afterwards.
Reviewers: ldionne, EricWF
Reviewed By: EricWF
Subscribers: christof, libcxx-commits
Differential Revision: https://reviews.llvm.org/D54814
llvm-svn: 347787
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
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
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
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
Summary:
Some tests (mainly the new C++20 calendar library) fail when libc++ is
tested with '--param=std=c++98'. The failures happen because the tests
actually don't support C++98, but don't mention C++98 in the
'UNSUPPORTED:' line.
This change fixes the issue.
Reviewers: mclow.lists, ldionne
Reviewed By: ldionne
Subscribers: arphaman, michaelplatings, libcxx-commits
Differential Revision: https://reviews.llvm.org/D53640
llvm-svn: 345148
The test is trying to avoid saying aligned_alloc on Windows' UCRT, which does not (and can not) implement aligned_alloc. However, it's testing for c1xx, meaning clang on Windows will fail this test when using the UCRT.
llvm-svn: 344829
In this example, the ctor of G runs in the main thread in the expression G(), and also in the copy ctor of G() in the DECAY_COPY inside std::thread. The main thread destroys the G() instance at the semicolon, and the started thread destroys the G() after it returns. Thus there is a race between the threads on the n_alive variable.
The fix is to join with the background thread before attempting to destroy the G in the main thread.
llvm-svn: 344820
Revert r344535 "Wrap up the new chrono literals in an #ifdef..."
Revert r344546 "Mark a couple of test cases as 'C++17-only'..."
Some of the buildbot failures were masked by another error,
and this one was probably missed.
llvm-svn: 344580
PR38682 added a test to check for a race condition in std::future.
Part of the fix is part of the dylib, but there is no released version
of mac OS X that ships a dylib containing the fix. Hence, this test can
(and sometimes does) when testing on OS X. This commit marks the test
as unsupported to avoid spurious failures.
llvm-svn: 344053
Debian build bots are running Clang 4, which apparently does not support
the "deprecated" attribute properly. Clang pretends to support the attribute,
but the attribute doesn't do anything.
(live example: https://wandbox.org/permlink/0De69aXns0t1D59r)
On a separate note, I'm not sure I understand why we're even running the
libc++ tests under Clang-4. Is this a configuration we support? I can
understand that libc++ should _build_ with Clang 4, but it's not clear
to me that new libc++ headers should be usable under older compilers
like that.
llvm-svn: 342854
Summary:
These deprecation warnings are opt-in: they are only enabled when the
_LIBCXX_DEPRECATION_WARNINGS macro is defined, which is not the case
by default. Note that this is a first step in the right direction, but
I wasn't able to get an exhaustive list of all deprecated components
per standard, so there's certainly stuff that's missing. The list of
components this commit marks as deprecated is:
in C++11:
- auto_ptr, auto_ptr_ref
- binder1st, binder2nd, bind1st(), bind2nd()
- pointer_to_unary_function, pointer_to_binary_function, ptr_fun()
- mem_fun_t, mem_fun1_t, const_mem_fun_t, const_mem_fun1_t, mem_fun()
- mem_fun_ref_t, mem_fun1_ref_t, const_mem_fun_ref_t, const_mem_fun1_ref_t, mem_fun_ref()
in C++14:
- random_shuffle()
in C++17:
- unary_negate, binary_negate, not1(), not2()
<rdar://problem/18168350>
Reviewers: mclow.lists, EricWF
Subscribers: christof, dexonsmith, llvm-commits
Differential Revision: https://reviews.llvm.org/D48912
llvm-svn: 342843
One of the SIMD tests attempted to left shift a value by 42, which
is UB when the left hand side is a 32 bit integer type.
This patch adjusts the test to use the value 4 instead of 42.
llvm-svn: 342820
This reverts r342566 as it causes on bots linker errors like
> Undefined symbols for architecture i386:
> "std::__1::basic_ostream<char, std::__1::char_traits<char> >::operator<<(std::nullptr_t)", referenced from:
llvm-svn: 342599
type.
Libc++ correctly asserts that a set of visitors for a variant all
return the same type. However, we use the visitation machinary to
perform relational operations. This causes a static assertion when
some of the alternatives relops return a UDT which is implicitly
convertible to bool instead of 'bool' exactly.
llvm-svn: 342560
Summary:
This commit fixes a regression introduced in r316095, where we don't match
inverted character classes when there's no negated characrers in the []'s.
rdar://problem/43060054
Reviewers: mclow.lists, timshen, EricWF
Subscribers: christof, dexonsmith, cfe-commits
Differential Revision: https://reviews.llvm.org/D50534
llvm-svn: 340609
Summary:
The state associated to the future was set in one thread (with synchronization)
but read in another thread without synchronization, which led to a data race.
https://bugs.llvm.org/show_bug.cgi?id=38181
rdar://problem/42548261
Reviewers: mclow.lists, EricWF
Subscribers: christof, dexonsmith, cfe-commits
Differential Revision: https://reviews.llvm.org/D51170
llvm-svn: 340608
These algorithms require a ForwardIterator or better. Ensure
we diagnose the contract violation at compile time instead of
of silently doing the wrong thing.
Further algorithms will be audited in upcoming patches.
llvm-svn: 340426
Summary:
When a seed sequence would lead to having no non-zero significant bits
in the initial state of a `mersenne_twister_engine`, the fallback is to
flip the most significant bit of the first value that appears in the
textual representation of the initial state.
rand.eng.mers describes this as setting the value to be 2 to the power
of one less than w; the previous value encoded in the implementation,
namely one less than "2 to the power of w", is replaced by the correct
value in this patch.
Reviewers: mclow.lists, EricWF, jasonliu
Reviewed By: mclow.lists
Subscribers: mclow.lists, jasonliu, EricWF, christof, ldionne, cfe-commits
Differential Revision: https://reviews.llvm.org/D50736
llvm-svn: 339969
Summary:
Since r338934, Clang emits an error when aligned allocation functions are
used in conjunction with a system libc++ dylib that does not support those
functions. This causes some tests to fail when testing against older libc++
dylibs. This commit marks those tests as UNSUPPORTED, and also documents the
various reasons for the tests being unsupported.
Reviewers: vsapsai, EricWF
Subscribers: christof, dexonsmith, cfe-commits, mclow.lists, EricWF
Differential Revision: https://reviews.llvm.org/D50341
llvm-svn: 339743
Summary:
Those tests are breaking the test bots. A Bugzilla has been filed to
make sure those tests are re-enabled: https://bugs.llvm.org/show_bug.cgi?id=38572
Reviewers: mclow.lists, EricWF
Subscribers: krytarowski, christof, dexonsmith, cfe-commits
Differential Revision: https://reviews.llvm.org/D50748
llvm-svn: 339742
Summary:
These #includes are quite important, since otherwise any
#if TEST_STD_VER > 14 && defined(TEST_HAS_C11_FEATURES)
checks are always false, and so we don't actually test for C11 support
in the standard library.
Reviewers: mclow.lists, EricWF
Subscribers: christof, dexonsmith, cfe-commits
Differential Revision: https://reviews.llvm.org/D50674
llvm-svn: 339675
(Still pending review at https://reviews.llvm.org/D47400 which has been open since may; will ask for forgiveness rather than permission :) )
llvm-svn: 339214
I'm not sure if libcxx is asserting UTF-8 here; but on Windows the full char value is always passed through in its entirety, since the default codepage is something like Windows-1252. The replacement character is only used for non-chars there; and that should be a more portable test everywhere.
(Still pending review at https://reviews.llvm.org/D47395 which has been open since may; will ask for forgiveness rather than permission :) )
llvm-svn: 339213
Summary:
Major QoI considerations:
- The facility is backported to C++14, same as libstdc++.
- Efforts have been made to minimize the header dependencies.
- The design is friendly to the uses of MSVC intrinsics (`__emulu`, `_umul128`, `_BitScanForward`, `_BitScanForward64`) but not implemented; future contributions are welcome.
Thanks to Milo Yip for contributing the implementation of `__u64toa` and `__u32toa`.
References:
https://wg21.link/p0067r5https://wg21.link/p0682r1
Reviewers: mclow.lists, EricWF
Reviewed By: mclow.lists
Subscribers: ldionne, Quuxplusone, christof, mgorny, cfe-commits
Differential Revision: https://reviews.llvm.org/D41458
llvm-svn: 338479
This commit adds a node handle type, (located in __node_handle), and adds
extract() and insert() members to all map and set types, as well as their
implementations in __tree and __hash_table.
The second half of this feature is adding merge() members, which splice nodes
in bulk from one container into another. This will be committed in a follow-up.
Differential revision: https://reviews.llvm.org/D46845
llvm-svn: 338472
Summary:
This patch adds a new macro _LIBCPP_HAS_NO_VECTOR_EXTENSION for detecting
whether a vector extension (\_\_attribute\_\_((vector_size(num_bytes)))) is
available.
On the top of that, this patch implements the following API:
* all constructors
* operator[]
* copy_from
* copy_to
It also defines simd_abi::native to use vector extension, if available.
In GCC and Clang, certain values with vector extension are passed by registers,
instead of memory.
Based on D41148.
Reviewers: mclow.lists, EricWF
Subscribers: cfe-commits, MaskRay, lichray, sanjoy
Differential Revision: https://reviews.llvm.org/D41376
llvm-svn: 338309
This patch implements the <filesystem> header and uses that
to provide <experimental/filesystem>.
Unlike other standard headers, the symbols needed for <filesystem>
have not yet been placed in libc++.so. Instead they live in the
new libc++fs.a library. Users of filesystem are required to link this
library. (Also note that libc++experimental no longer contains the
definition of <experimental/filesystem>, which now requires linking libc++fs).
The reason for keeping <filesystem> out of the dylib for now is that
it's still somewhat experimental, and the possibility of requiring an
ABI breaking change is very real. In the future the symbols will likely
be moved into the dylib, or the dylib will be made to link libc++fs automagically).
Note that moving the symbols out of libc++experimental may break user builds
until they update to -lc++fs. This should be OK, because the experimental
library provides no stability guarantees. However, I plan on looking into
ways we can force libc++experimental to automagically link libc++fs.
In order to use a single implementation and set of tests for <filesystem>, it
has been placed in a special `__fs` namespace. This namespace is inline in
C++17 onward, but not before that. As such implementation is available
in C++11 onward, but no filesystem namespace is present "directly", and
as such name conflicts shouldn't occur in C++11 or C++14.
llvm-svn: 338093
Summary:
The ``file_time_type`` time point is used to represent the write times for files.
Its job is to act as part of a C++ wrapper for less ideal system interfaces. The
underlying filesystem uses the ``timespec`` struct for the same purpose.
However, the initial implementation of ``file_time_type`` could not represent
either the range or resolution of ``timespec``, making it unsuitable. Fixing
this requires an implementation which uses more than 64 bits to store the
time point.
I primarily considered two solutions: Using ``__int128_t`` and using a
arithmetic emulation of ``timespec``. Each has its pros and cons, and both
come with more than one complication.
However, after a lot of consideration, I decided on using `__int128_t`. This patch implements that change.
Please see the [FileTimeType Design Document](http://libcxx.llvm.org/docs/DesignDocs/FileTimeType.html) for more information.
Reviewers: mclow.lists, ldionne, joerg, arthur.j.odwyer, EricWF
Reviewed By: EricWF
Subscribers: christof, K-ballo, cfe-commits, BillyONeal
Differential Revision: https://reviews.llvm.org/D49774
llvm-svn: 337960
Libc++ was incorrectly reporting an error when the target of create_directory
already exists, but was not a directory. This behavior is not specified
in the most recent standard, which says no error should be reported.
Additionally, libc++ failed to report an error when the attribute directory
path didn't exist or didn't name a directory. This has been fixed as well.
Although it's not clear if we should call status or symlink_status on the
attribute directory. This patch chooses to still call status.
llvm-svn: 337888
Previously the <experimental/filesystem> didn't guard its
contents in any dialect. However, the implementation implicitly
requires at least C++11, and the tests have always been marked
unsupported in C++03. This patch puts a header guard around the
contents to avoid exposing them before C++11.
Additionally, it replaces all of the usages of _NOEXCEPT or
_LIBCPP_CONSTEXPR with the keyword directly, since we can
expect the compiler to implement those by now.
llvm-svn: 337884
When adding the new tests for the filesystem_error::what method,
I incorrectly removed a test case and replaced it with something else.
This patch restores that test case
llvm-svn: 337764
This patch implements the `what()` for filesystem errors. The message
includes the 'what_arg', any paths that were specified, and the
error code message.
Additionally this patch refactors how errors are created, making it easier
to report them correctly.
llvm-svn: 337664
This patch improves both the performance, and the safety of the
copy_file implementation.
The performance improvements are achieved by using sendfile on
Linux and copyfile on OS X when available.
The TOCTOU hardening is achieved by opening the source and
destination files and then using fstat to check their attributes to
see if we can copy them.
Unfortunately for the destination file, there is no way to open
it without accidentally creating it, so we first have to use
stat to determine if it exists, and if we should copy to it.
Then, once we're sure we should try to copy, we open the dest
file and ensure it names the same entity we previously stat'ed.
llvm-svn: 337649
Summary:
This patch implements directory_entry caching *almost* as specified in P0317r1. However, I explicitly chose to deviate from the standard as I'll explain below.
The approach I decided to take is a fully caching one. When `refresh()` is called, the cache is populated by calls to `stat` and `lstat` as needed.
During directory iteration the cache is only populated with the `file_type` as reported by `readdir`.
The cache can be in the following states:
* `_Empty`: There is nothing in the cache (likely due to an error)
* `_IterSymlink`: Created by directory iteration when we walk onto a symlink only the symlink file type is known.
* `_IterNonSymlink`: Created by directory iteration when we walk onto a non-symlink. Both the regular file type and symlink file type are known.
* `_RefreshSymlink` and `_RefreshNonSymlink`: A full cache created by `refresh()`. This case includes dead symlinks.
* `_RefreshSymlinkUnresolved`: A partial cache created by refresh when we fail to resolve the file pointed to by a symlink (likely due to permissions). Symlink attributes are cached, but attributes about the linked entity are not.
As mentioned, this implementation purposefully deviates from the standard. According to some readings of the specification, and the Windows filesystem implementation, the constructors and modifiers which don't pass an `error_code` must throw when the `directory_entry` points to a entity which doesn't exist. or when attribute resolution fails for another reason.
@BillyONeal has proposed a more reasonable set of requirements, where modifiers other than refresh ignore errors. This is the behavior libc++ currently implements, with the expectation some form of the new language will be accepted into the standard.
Some additional semantics which differ from the Windows implementation:
1. `refresh` will not throw when the entry doesn't exist. In this case we can still meet the functions specification, so we don't treat it as an error.
2. We don't clear the path name when a constructor fails via refresh (this will hopefully be changed in the standard as well).
It should be noted that libstdc++'s current implementation has the same behavior as libc++, except for point (2).
If the changes to the specification don't get accepted, we'll be able to make the changes later.
[1] http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0317r1.html
Reviewers: mclow.lists, gromer, ldionne, aaron.ballman
Subscribers: BillyONeal, christof, cfe-commits
Differential Revision: https://reviews.llvm.org/D49530
llvm-svn: 337516
* Remove unused type from is_assignable.pass.cpp
* Don't specialize `common_type<::X<float>>` in common_type.pass.cpp, which violates the requirements of [meta.trans.other]/5
llvm-svn: 336618
When built against the old libc++ version the test was causing linker error
Undefined symbols for architecture x86_64:
"std::experimental::fundamentals_v1::pmr::new_delete_resource()", referenced from:
void test_evil<WidgetV0, WidgetV0>() in construct_piecewise_pair_evil.pass.cpp.o
void test_evil<WidgetV0, WidgetV1>() in construct_piecewise_pair_evil.pass.cpp.o
void test_evil<WidgetV0, WidgetV2>() in construct_piecewise_pair_evil.pass.cpp.o
void test_evil<WidgetV0, WidgetV3>() in construct_piecewise_pair_evil.pass.cpp.o
void test_evil<WidgetV1, WidgetV0>() in construct_piecewise_pair_evil.pass.cpp.o
void test_evil<WidgetV1, WidgetV1>() in construct_piecewise_pair_evil.pass.cpp.o
void test_evil<WidgetV1, WidgetV2>() in construct_piecewise_pair_evil.pass.cpp.o
...
llvm-svn: 334431
C++2a[container.requirements.general]p8 states that when move constructing
a container, the allocator is move constructed. Vector previously copy
constructed these allocators. This patch fixes that bug.
Additionally it cleans up some unnecessary allocator conversions
when copy constructing containers. Libc++ uses
__internal_allocator_traits::select_on_copy_construction to select
the correct allocator during copy construction, but it unnecessarily
converted the resulting allocator to the user specified allocator
type and back. After this patch list and forward_list no longer
do that.
Technically we're supposed to be using allocator_traits<allocator_type>::select_on_copy_construction,
but that should seemingly be addressed as a separate patch, if at all.
llvm-svn: 334053
Summary:
The filesystem test was confused about access versus write / modification time. The spec says:
file_time_type last_write_time(const path& p, error_code& ec) noexcept;
Returns: The time of last data modification of p, determined as if by the value of the POSIX stat structure member st_mtime obtained as if by POSIX stat(). The signature with argument ec returns file_time_type::min() if an error occurs.
The test was looking at st_atime, not st_mtime, when comparing the result from last_write_time. That was probably due to using a pair instead of naming things nicely or using types. I opted to rename things so it's clearer.
This used to cause test bot failures.
<rdar://problem/40648859>
Reviewers: EricWF, mclow.lists, aemerson
Subscribers: christof, cfe-commits
Differential Revision: https://reviews.llvm.org/D47557
llvm-svn: 333723
Patch from Arthur O'Dwyer.
In the TS, `uses_allocator` construction for `pair` tried to use an allocator
type of `memory_resource*`, which is incorrect because `memory_resource*` is
not an allocator type. LWG 2969 fixed it to use `polymorphic_allocator` as the
allocator type instead.
https://wg21.link/lwg2969
(D47090 included this in `<memory_resource>`; at Eric's request, I've split
this out into its own patch applied to the existing
`<experimental/memory_resource>` instead.)
Reviewed as https://reviews.llvm.org/D47109
llvm-svn: 333384
Checking for complete types is really rather tricky when you consider
the amount of specializations required to check a function type. This
specifically caused PR37407 where we incorrectly diagnosed
noexcept function types as incomplete (but there were plenty of other
cases that would cause this).
This patch removes the complete type checking for now. I'm going
to look into adding a clang builtin to correctly do this for us.
llvm-svn: 332040
When using an old version of glibc, a ::isinf(double) and ::isnan(double)
function is provided, rather than just the macro required by C and C++.
Displace this function using _LIBCPP_PREFERRED_OVERLOAD where possible.
The only remaining case where we should get the wrong return type is now
glibc + libc++ + a non-clang compiler.
llvm-svn: 331241
seekoff.pass.cpp:
libc++'s tests are asserting things about the buffer passed to pubsetbuf. [filebuf.virtuals]/12 says that what the filebuf does with the buffer you give it is completely implementation defined. The MSVC++ implementation takes that buffer and hands it off to the CRT (by calling ::setvbuf) and the CRT doesn't necessarily follow the pattern this test wants.
This change simply makes asserts against the buffer's contents use LIBCPP_ASSERT instead of assert.
pbackfail.pass.cpp:
libc++'s tests are asserting about what characters will and will not be available in the putback area. [filebuf.virtuals]/9 says "The function can alter the number of putback positions available as a result of any call." This change LIBCPP_ASSERTS libc++'s behavior, but checks invariants of the putback area independently.
llvm-svn: 330999
Be defensive against a reentrant std::function::operator=(nullptr_t), in case
the held function object has a non-trivial destructor. Destroying the function
object in-place can lead to the destructor being called twice.
Patch by Duncan P. N. Exon Smith. C++03 support by Volodymyr Sapsai.
rdar://problem/32836603
Reviewers: EricWF, mclow.lists
Reviewed By: mclow.lists
Subscribers: cfe-commits, arphaman
Differential Revision: https://reviews.llvm.org/D34331
llvm-svn: 330885
These io_error asserts that std::errc::is_a_directory has message "Is a directory". On MSVC++ it reports "is a directory" (with a lowercase I). That doesn't matter for the ios_failure component being tested, so just implement in terms of system_category().message().
Reviewed as https://reviews.llvm.org/D45715
llvm-svn: 330791
There are 3 changes:
* Renamed genertor.pass.cpp to generator.pass.cpp
* Removed nothing_to_do.pass.cpp
* Mark GCC 4.9 as UNSUPPORTED for the test files that have negative
narrowing conversion SFINAE test (see GCC PR63723).
llvm-svn: 330655
Summary:
The patch includes all declarations, and also implements the following features:
* ABI.
* narrowing-conversion related SFIANE, including simd<> ctors and (static_)simd_cast.
Reviewers: mclow.lists, EricWF
Subscribers: lichray, sanjoy, MaskRay, cfe-commits
Differential Revision: https://reviews.llvm.org/D41148
llvm-svn: 330627
This test code triggers the MSVC warning:
"unary minus operator applied to unsigned type, result still unsigned"
Although it would be possible to change the test code to avoid
this warning, I have chosen to simply silence it.
Fixes D45594.
llvm-svn: 329976
MSVC emits "warning C4244: 'initializing': conversion from 'int'
to 'short', possible loss of data" when it sees pair<Whatever, short>
constructed from (whatever, 4), because int is being truncated to
short within pair's constructor. (The compiler doesn't take into
account the fact that 4 is a literal at the callsite; it generates
this warning when the constructor is instantiated, because it might
be called with a runtime-valued int that would actually truncate.)
Instead of static_cast<short>, we can simply change short to int
in these tests, without affecting the pair operations that they're
trying to test: move assignment, convert copy construction, and
convert move construction.
Fixes D45016.
llvm-svn: 329973
Patch from Joe Loser.
Several unit tests meaning to test the behavior of lvalue insertion incorrectly
pass rvalues. Fixes bug PR # 27394
Reviewed as https://reviews.llvm.org/D44411
llvm-svn: 329541
Summary:
D44883 extends -Wself-assign to also work on C++ classes.
These new warnings pop up in the test suite, so they have to be silenced.
Please refer to the D45082 for disscussion on whether this is the right way to solve this.
Testing: `ninja check-libcxx check-libcxxabi` in stage-2 build.
Reviewers: mclow.lists, EricWF
Reviewed By: EricWF
Subscribers: Quuxplusone, cfe-commits
Differential Revision: https://reviews.llvm.org/D45128
llvm-svn: 329490
this patch adds the <compare> header and implements all of it
except for [comp.alg].
As I understand it, the header is needed by the compiler in
when implementing the semantics of operator<=>. For that reason
I feel it's important to land this header early, despite
all compilers lacking support.
llvm-svn: 329460
GLIBC 2.27 changed the locale data for fr_FR and ru_RU. In particular
they change the decimal and thousands separators used. This patch
makes the locale tests tolerate the updated locales.
llvm-svn: 329143
This patch implements P0430R2, who's largest change is adding the path::format
enumeration for supporting path format conversions in path constructors.
However, since libc++'s filesystem only really supports POSIX like systems,
there are no real changes needed. This patch simply adds the format enum
and then ignores it when it's passed to constructors.
llvm-svn: 329031
This is a fairly large patch that implements all of the filesystem NB comments
and the relative paths changes (ex. adding weakly_canonical). These issues
and papers are all interrelated so their implementation couldn't be split up
nicely.
This patch upgrades <experimental/filesystem> to match the C++17 spec and not
the published experimental TS spec. Some of the changes in this patch are both
API and ABI breaking, however libc++ makes no guarantee about stability for
experimental implementations.
The major changes in this patch are:
* Implement NB comments for filesystem (P0492R2), including:
* Implement `perm_options` enum as part of NB comments, and update the
`permissions` function to match.
* Implement changes to `remove_filename` and `replace_filename`
* Implement changes to `path::stem()` and `path::extension()` which support
splitting examples like `.profile`.
* Change path iteration to return an empty path instead of '.' for trailing
separators.
* Change `operator/=` to handle absolute paths on the RHS.
* Change `absolute` to no longer accept a current path argument.
* Implement relative paths according to NB comments (P0219r1)
* Combine `path.cpp` and `operations.cpp` since some path functions require
access to the operations internals, and some fs operations require access
to the path parser.
llvm-svn: 329028
Libc++ implements the pair& operator=(pair<U, V>) assignment operator
using a single template that handles assignment from all tuple-like types.
This patch moves the test for that to the libcxx test directory since
it's non-standard. It also adds additional tests to the std/.../pair
directory to test the standard behavior this template implements.
llvm-svn: 328758
This patch corrects num_get for unsigned types to support strings
with a leading `-` character. According to the standard the
number should be parsed as an unsigned integer and then
negated.
llvm-svn: 328751
The NB comments for filesystem changed permissions and added
a new enum `perm_options` which control how the permissions
are applied.
This implements than NB resolution
llvm-svn: 328476
As I move towards implementing std::filesystem, there is a need to
make the existing tests run against both the std and experimental versions.
Additionally, it's helpful to allow running the tests against other
implementations of filesystem.
This patch converts the test to easily target either. First, it
adds a filesystem_include.hpp header which is soley responsible
for selecting and including the correct implementation. Second,
it converts existing tests to use this header instead of including
filesystem directly.
llvm-svn: 328475
Some debian libc++ bots started having failures in the locale
tests due to what I assume is a change in the locale data for fr_FR
in glibc.
This change prints the actual value from the test to help debugging.
It should be reverted once the bots cycle.
llvm-svn: 328268
This patch works around variant test failures which are new to
GCC 8. GCC 8 either doesn't perform SFINAE in lexical order, or
it doesn't halt after encountering the first failure. This
causes hard error to occur instead of substitution failure.
See gcc.gnu.org/PR78489
llvm-svn: 328261
The new/delete tests, in particular those which test replacement
functions, often fail when the optimizer is enabled because the
calls to new/delete may be optimized away, regardless of their side-effects.
This patch converts the tests to use DoNotOptimize in order to prevent
the elision.
llvm-svn: 328245
This patch fixes std::allocator, and more specifically, all users
of __libcpp_allocate and __libcpp_deallocate, to support over-aligned
types.
__libcpp_allocate/deallocate now take an alignment parameter, and when
the specified alignment is greater than that supported by malloc/new,
the aligned version of operator new is called (assuming it's available).
When aligned new isn't available, the old behavior has been kept, and the
alignment parameter is ignored.
This patch depends on recent changes to __builtin_operator_new/delete which
allow them to be used to call any regular new/delete operator. By using
__builtin_operator_new/delete when possible, the new/delete erasure optimization
is maintained.
llvm-svn: 328180
After two failed attempts last week to make this work I am
going back to a known good method of making this test pass on
macOS...adding the current apple-clang version to the
UNSUPPORTED list.
During a previous patch review (https://reviews.llvm.org/D44103)
it was suggested to just XFAIL libcpp-no-deduction-guides
as was done to iter_alloc_deduction.pass.cpp. However
this caused a an unexpected pass on:
http://lab.llvm.org:8011/builders/libcxx-libcxxabi-x86_64-linux-ubuntu-gcc-tot-latest-std/builds/214
I then attempted to just mark libcpp-no-deduction-guides
as UNSUPPORTED, however this caused an additional bot
failure. So I reverted everything (https://reviews.llvm.org/rCXX327191).
To solve this and get work unblocked I am adding
apple-clang-9 to the original UNSUPPORTED list.
llvm-svn: 327304
Summary: Refactor the previous version method of marking each apple-clang version as UNSUPPORTED and just XFAIL'ing the libcpp-no-deduction-guides instead. This brings this test inline with the same style as iter_alloc_deduction.pass.cpp
Reviewers: EricWF, dexonsmith
Reviewed By: EricWF
Subscribers: EricWF, vsapsai, vsk, cfe-commits
Differential Revision: https://reviews.llvm.org/D44103
llvm-svn: 327178
APFS minimum supported file write time is -2^63 nanoseconds, which doesn't go
as far as `file_time_type::min()` that is equal to -2^63 microseconds on macOS.
This change doesn't affect filesystems that support `file_time_type` range only
for in-memory file time representation but not for on-disk representation. Such
filesystems are considered as `SupportsMinTime`.
rdar://problem/35865151
Reviewers: EricWF, Hahnfeld
Subscribers: jkorous-apple, mclow.lists, cfe-commits, christof
Differential Revision: https://reviews.llvm.org/D42755
llvm-svn: 326383
test/std/numerics/numeric.ops/exclusive.scan/exclusive_scan.pass.cpp
test/std/numerics/numeric.ops/exclusive.scan/exclusive_scan_init_op.pass.cpp
test/std/numerics/numeric.ops/inclusive.scan/inclusive_scan.pass.cpp
test/std/numerics/numeric.ops/inclusive.scan/inclusive_scan_op.pass.cpp
test/std/numerics/numeric.ops/inclusive.scan/inclusive_scan_op_init.pass.cpp
test/std/numerics/numeric.ops/transform.exclusive.scan/transform_exclusive_scan_init_bop_uop.pass.cpp
test/std/numerics/numeric.ops/transform.inclusive.scan/transform_inclusive_scan_bop_uop.pass.cpp
test/std/numerics/numeric.ops/transform.inclusive.scan/transform_inclusive_scan_bop_uop_init.pass.cpp
Fix MSVC x64 truncation warnings.
warning C4267: conversion from 'size_t' to 'int', possible loss of data
test/std/strings/basic.string/string.modifiers/string_append/push_back.pass.cpp
Fix MSVC uninitialized memory warning.
warning C6001: Using uninitialized memory 'vl'.
test/std/utilities/tuple/tuple.tuple/tuple.cnstr/PR20855_tuple_ref_binding_diagnostics.pass.cpp
Include <cassert> for the assert() macro.
Fixes D43273.
llvm-svn: 326120
Summary:
Currently std::asinh and std::acosh use std::pow to compute x^2. This
results in a significant error when computing e.g. asinh(i) or
acosh(-1).
This patch expresses x^2 directly via x.real() and x.imag(), like it
is done in libstdc++/glibc, and adds tests that checks the accuracy.
Reviewers: EricWF, mclow.lists
Reviewed By: mclow.lists
Subscribers: christof, cfe-commits
Differential Revision: https://reviews.llvm.org/D41629
llvm-svn: 325510
Patch from ngolovliov@gmail.com
Reviewed as: https://reviews.llvm.org/D42344
As described in llvm.org/PR30959, the current
implementation of std::{map, key}::{count, equal_range} in libcxx is
non-conforming. Quoting the C++14 standard [associative.reqmts]p3
> The phrase “equivalence of keys” means the equivalence relation imposed by
> the comparison and not the operator== on keys. That is, two keys k1 and k2 are
> considered to be equivalent if for the comparison object comp,
> comp(k1, k2) == false && comp(k2, k1) == false.
In the same section, the requirements table states the following:
> a.equal_range(k) equivalent to make_pair(a.lower_bound(k), a.upper_bound(k))
> a.count(k) returns the number of elements with key equivalent to k
The behaviour of libstdc++ seems to conform to the standard here.
llvm-svn: 324799
Eric Fiselier