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
In rL342814, i have committed a blind fix to unbreak the asan buildbot,
but as it was later discussed, the leak is intentional,
so we can not fix the failure that way.
So this reverts the leak 'fix',
and simply disables the test in the presence of ASAN.
llvm-svn: 342819
Summary:
The `[[nodiscard]]` attribute is intended to help users find bugs where
function return values are ignored when they shouldn't be. After C++17 the
C++ standard has started to declared such library functions as `[[nodiscard]]`.
However, this application is limited and applies only to dialects after C++17.
Users who want help diagnosing misuses of STL functions may desire a more
liberal application of `[[nodiscard]]`.
For this reason libc++ provides an extension that does just that! The
extension must be enabled by defining `_LIBCPP_ENABLE_NODISCARD`. The extended
applications of `[[nodiscard]]` takes two forms:
1. Backporting `[[nodiscard]]` to entities declared as such by the
standard in newer dialects, but not in the present one.
2. Extended applications of `[[nodiscard]]`, at the libraries discretion,
applied to entities never declared as such by the standard.
Users may also opt-out of additional applications `[[nodiscard]]` using
additional macros.
Applications of the first form, which backport `[[nodiscard]]` from a newer
dialect may be disabled using macros specific to the dialect it was added. For
example `_LIBCPP_DISABLE_NODISCARD_AFTER_CXX17`.
Applications of the second form, which are pure extensions, may be disabled
by defining `_LIBCPP_DISABLE_NODISCARD_EXT`.
This patch was originally written by me (Roman Lebedev),
then but then reworked by Eric Fiselier.
Reviewers: mclow.lists, thakis, EricWF
Reviewed By: thakis, EricWF
Subscribers: llvm-commits, mclow.lists, lebedev.ri, EricWF, rjmccall, Quuxplusone, cfe-commits, christof
Differential Revision: https://reviews.llvm.org/D45179
llvm-svn: 342808
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
It looks like this test XPASSes when the deployment target is older than
the OS of the system the test is running on. It looks like we run the
tests with -mmacosx-version-min=10.12, and that makes the test expect to
fail, but it passes.
llvm-svn: 340427
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
Because FreeBSD uses _M in its <sys/types.h>, and it is hard to avoid
including that header, only define _M to NASTY_MACRO for other operating
systems. This fixes almost 2000 unexpected test failures.
Discussed with Eric Fiselier.
llvm-svn: 339794
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:
The macro was not defined in C++11 mode when it should have been, at least
according to how _LIBCPP_HAS_C11_FEATURES is defined.
Reviewers: mclow.lists, EricWF, jfb, dexonsmith
Subscribers: christof, dexonsmith, cfe-commits
Differential Revision: https://reviews.llvm.org/D50719
llvm-svn: 339702
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
Summary:
The current code enables aligned allocation functions when compiling in C++17
and later. This is a problem because aligned allocation functions might not
be supported on the target platform, which leads to an error at link time.
Since r338934, Clang knows not to define __cpp_aligned_new when it's not
available on the target platform -- this commit takes advantage of that to
only use aligned allocation functions when they are available.
Reviewers: vsapsai, EricWF
Subscribers: christof, dexonsmith, cfe-commits, EricWF, mclow.lists
Differential Revision: https://reviews.llvm.org/D50344
llvm-svn: 339431
(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
The bots were failing to build the cxx_filesystem target, so the
tests were failing. Though this does lead me to wonder how it
was ever working with c++experimental.
llvm-svn: 338095
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
Tuple has tests that ensure we diagnose non-lifetime extended
reference bindings inside tuples constructors. As of yesterday,
Clang now does this for us.
Adjust the test to tolerate the new diagnostics, while still
testing that we emit diagnostics of our own. Maybe after this
version of Clang has been adopted by most users we should
remove our diagnostics; but for now more error detection is
better!
llvm-svn: 337905
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
Summary:
This is not guaranteed to work since the characters after '__has_include('
have special lexing rules that can't possibly be applied when
__has_include is generated by a macro. It also breaks the crash reproducers
generated by -frewrite-includes (see https://llvm.org/pr37990).
Reviewers: EricWF, rsmith, mclow.lists
Reviewed By: mclow.lists
Differential Revision: https://reviews.llvm.org/D49067
llvm-svn: 337824
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
First, <experimental/filesystem> didn't correctly guard
against min/max macros. This adds the proper push/pop macro guards.
Second, an internal time helper had been renamed but the test for
it hadn't been updated. This patch updates those tests.
llvm-svn: 337520
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
That's r333325, as well as follow-up "Fix GCC handling of ATOMIC_VAR_INIT"
r333327.
Marshall asked to revert:
Let's have a discussion about how to implement this so that it is more friendly
to people with installed code bases. We've had *extremely* loud responses to
unilaterally adding warnings - especially ones that can't be easily disabled -
to the libc++ code base in the past.
llvm-svn: 333351
r333325 from D47225 added warning checks, and the test was written to be C++11 correct by using ATOMIC_VAR_INIT (note that the committee fixed that recently...). It seems like GCC can't handle ATOMIC_VAR_INIT well because it generates 'type 'std::atomic<int>' cannot be initialized with an initializer list' on bot libcxx-libcxxabi-x86_64-linux-ubuntu-cxx03. Drop the ATOMIC_VAR_INITs since they weren't required to test the diagnostics.
llvm-svn: 333327
Summary:
The atomic non-member functions accept pointers to std::atomic / std::atomic_flag as well as to the non-atomic value. These are all dereferenced unconditionally when lowered, and therefore will fault if null. It's a tiny gotcha for new users, especially when they pass in NULL as expected value (instead of passing a pointer to a NULL value). We can therefore use the nonnull attribute to denote that:
- A warning should be generated if the argument is null
- It is undefined behavior if the argument is null (because a dereference will segfault)
This patch adds support for this attribute for clang and GCC, and sticks to the subset of the syntax both supports. In particular, work around this GCC oddity:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60625
The attributes are documented:
- https://gcc.gnu.org/onlinedocs/gcc-4.0.0/gcc/Function-Attributes.html
- https://clang.llvm.org/docs/AttributeReference.html#nullability-attributes
I'm authoring a companion clang patch for the __c11_* and __atomic_* builtins, which currently only warn on a subset of the pointer parameters.
In all cases the check needs to be explicit and not use the empty nonnull list, because some of the overloads are for atomic<T*> and the values themselves are allowed to be null.
<rdar://problem/18473124>
Reviewers: arphaman, EricWF
Subscribers: aheejin, christof, cfe-commits
Differential Revision: https://reviews.llvm.org/D47225
llvm-svn: 333325
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
Atomics in C and C++ are incompatible at the moment and mixing the
headers can result in confusing error messages.
Emit an error explicitly telling about the incompatibility. Introduce
the macro `__ALLOW_STDC_ATOMICS_IN_CXX__` that allows to choose in C++
between C atomics and C++ atomics.
rdar://problem/27435938
Reviewers: rsmith, EricWF, mclow.lists
Reviewed By: mclow.lists
Subscribers: jkorous-apple, christof, bumblebritches57, JonChesterfield, smeenai, cfe-commits
Differential Revision: https://reviews.llvm.org/D45470
llvm-svn: 331379
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
Replace unary_function inheritance (which was never required,
even in C++98) with argument_type and result_type typedefs.
This increases portability, as unary_function was removed in C++17
and MSVC has implemented that removal.
Fixes D45596.
llvm-svn: 329974
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
This patch does some housekeeping for the new <version> header.
It adds it to the module.modulemap, and the double_include.sh.cpp test.
Additionally it corrects the // UNSUPPORTED options for the libc++
specific test. The header needs to compile under C++03 to support
modules, and it should compile under all available compilers.
llvm-svn: 329144
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 fixes a couple of tests which produced a warning that a 'throw'
occurred in a noexcept function (by way of _LIBCPP_ASSERT). It does
so by hiding the 'throw' across an opaque function boundary.
This fix isn't ideal, since we still have _LIBCPP_ASSERT's in functions
marked noexcept -- and this problem should be addressed in the future.
However, throwing _LIBCPP_ASSERT is really only meant to allow testing
of the assertions, and is not yet ready for general use.
llvm-svn: 328265
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
shrink_to_fit() ends up doing a lot work to get information that we
already know since we just called clear(). This change seems concise
enough to be worth the couple extra lines and my benchmarks show that it
is indeed a pretty decent win. It looks like the same thing is going on
twice in __copy_assign_alloc(), but I didn't want to go overboard since
this is my first contribution to llvm/libc++.
Patch by Timothy VanSlyke!
Differential Revision: https://reviews.llvm.org/D41976
llvm-svn: 327064
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:
These flags can be specified using the CMake variables
LIBCXX_TEST_LINKER_FLAGS and LIBCXX_TEST_COMPILER_FLAGS.
When building the tests for CHERI I need to pass additional
flags (such as -mabi=n64 or -mabi=purecap) to the compiler
for our test configurations
Reviewers: EricWF
Reviewed By: EricWF
Subscribers: christof, mgorny, cfe-commits
Differential Revision: https://reviews.llvm.org/D42139
llvm-svn: 325914
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
Summary:
Currently libc++ implements some operations on valarray by using the
resize method. This method has a parameter with a default value.
Because of this, valarray may spuriously construct and destruct
objects of valarray's element type.
This patch fixes this issue and adds corresponding test cases.
Reviewers: EricWF, mclow.lists
Reviewed By: mclow.lists
Subscribers: rogfer01, cfe-commits
Differential Revision: https://reviews.llvm.org/D41992
llvm-svn: 324596
An array T[1] isn't necessarily the same say when it's
a member of a struct. This patch addresses that problem and corrects
the tests to deal with it.
llvm-svn: 324545
Summary:
This patch fixes llvm.org/PR35491 and LWG2157 (https://cplusplus.github.io/LWG/issue2157)
The fix attempts to maintain ABI compatibility by replacing the array with a instance of `aligned_storage`.
Reviewers: mclow.lists, EricWF
Reviewed By: EricWF
Subscribers: lichray, cfe-commits
Differential Revision: https://reviews.llvm.org/D41223
llvm-svn: 324526
Revert "Fix initialization of array<const T, 0> with GCC."
Revert "Make array<const T, 0> non-CopyAssignable and make swap and fill ill-formed."
This reverts commit r324182, r324185, and r324194 which were causing issues with zero-length std::arrays.
llvm-svn: 324309
This patch removes the noexcept declaration from filesystem
operations which require creating temporary paths or
creating a directory iterator. Either of these operations
can throw.
llvm-svn: 324192
Because path can be constructed from a ton of different types, including string
and wide strings, this caused it's streaming operators to suck up all sorts
of silly types via silly conversions. For example:
using namespace std::experimental::filesystem::v1;
std::wstring w(L"wide");
std::cout << w; // converts to path.
This patch tentatively adopts the resolution to LWG2989 and fixes the issue
by making the streaming operators friends of path.
llvm-svn: 324189
The standard isn't exactly clear how std::array should handle zero-sized arrays
with const element types. In particular W.R.T. copy assignment, swap, and fill.
This patch takes the position that those operations should be ill-formed,
and makes changes to libc++ to make it so.
This follows up on commit r324182.
llvm-svn: 324185
Summary:
This patch fixes llvm.org/PR35491 and LWG2157 (https://cplusplus.github.io/LWG/issue2157)
The fix attempts to maintain ABI compatibility by replacing the array with a instance of `aligned_storage`.
Reviewers: mclow.lists, EricWF
Reviewed By: EricWF
Subscribers: lichray, cfe-commits
Differential Revision: https://reviews.llvm.org/D41223
llvm-svn: 324182
When Clang encounters an already invalid class declaration, it can
emit incorrect diagnostics about the exception specification on
some of its members. This patch temporarily works around that
incorrect diagnostic.
The clang bug was introduced in r324062.
llvm-svn: 324164
Clang previously reported an empty union as having a unique object
representation. This was incorrect and was fixed in a recent Clang commit.
This patch fixes the libc++ tests.
llvm-svn: 324153
According to [1], forms 2 and 4 of std::is_permutation should use the passed in
binary predicate to compare elements. operator== should only be used for forms
1 and 3 which do not take a binary predicate.
This CL fixes forms 2 and 4 which relied on operator== for some comparisons.
[1] http://en.cppreference.com/w/cpp/algorithm/is_permutation
Patch by Thomas Anderson!
Differential Revision: https://reviews.llvm.org/D42518
llvm-svn: 323563
Code on Windows expects to be able to do:
#define _USE_MATH_DEFINES
#include <math.h>
and receive the definitions of mathematical constants, even if <math.h>
has previously been included. To support this scenario, re-include
<math.h> every time the wrapper header is included.
Differential Revision: https://reviews.llvm.org/D42403
llvm-svn: 323490
There was a bug in the implementation of splice where the container
sizes were updated before decrementing one of the iterators. Afterwards,
the result of decrementing the iterator was flagged as UB by the debug
implementation because the container was reported to be empty.
This patch fixes that bug by delaying the updating of the container
sizes until after the iterators have been correctly constructed.
llvm-svn: 323390
Summary:
See https://bugs.llvm.org/show_bug.cgi?id=20855
Libc++ goes out of it's way to diagnose `std::tuple` constructions which are UB due to lifetime bugs caused by reference creation. For example:
```
// The 'const std::string&' is created *inside* the tuple constructor, and its lifetime is over before the end of the constructor call.
std::tuple<int, const std::string&> t(std::make_tuple(42, "abc"));
```
However, we are over-aggressive and we incorrectly diagnose cases such as:
```
void foo(std::tuple<int const&, int const&> const&);
foo(std::make_tuple(42, 42));
```
This patch fixes the incorrectly diagnosed cases, as well as converting the diagnostic to use the newly added Clang trait `__reference_binds_to_temporary`. The new trait allows us to diagnose cases we previously couldn't such as:
```
std::tuple<int, const std::string&> t(42, "abc");
```
Reviewers: rsmith, mclow.lists
Reviewed By: rsmith
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D41977
llvm-svn: 323380
Summary:
Currently when a regular expression contains an invalid character
class name std::regex constructors throw an std::regex_error with
std::regex_constants::error_brack code.
This patch changes the code to std::regex_constants::error_ctype and
adds a test.
Reviewers: EricWF, mclow.lists
Reviewed By: mclow.lists
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D42291
llvm-svn: 323322
This is an MSVC standard library extension. It seems like a reasonable
enough extension to me because wchar_t* is the native format for
filenames on that platform.
Differential Revision: https://reviews.llvm.org/D42225
llvm-svn: 323170
This patch fixes almost all currently failing tests when
using GCC ToT.
The specific changes are:
(A) Workaround gcc.gnu.org/PR83921 which rejects variables w/o initializers
in constexpr contexts -- even when the variable is an empty class. This
bug has been worked around at all callsites by adding an initializer.
Additionally a new test, constexpr_init.pass.cpp, has been added to
test that Clang doesn't suffer from these bugs.
(B) Fix streambuf.assign/swap.pass.cpp. This test was never actually
calling the swap method as intended. In fact, the swap function it
intended to call was ill-formed when instantiated. GCC diagnosed
this ill-formedness w/o needing an instantiation.
(C) size_delete11.pass.cpp was fixed by adding c++2a to the list of
unsupported dialects.
llvm-svn: 322810
Previously .fail.cpp tests for nodiscard were run with -Wunused-result
being a warning, not an error, when the compiler didn't support -verify.
When -verify isn't enabled this change judiciously adds -Werror=unused-result
when to only the failure tests containing the // expected-error string for nodiscard.
As a drive-by change, this patch also adds a missing // UNSUPPORTED: c++2a to
a test which was only supposed to run in C++ <= 11.
llvm-svn: 322776
It covers the cases when the sentry object returns false and when an exception
was thrown. Corresponding standard paragraph is C++14 [istream.unformatted]p9:
[...] In any case, if n is greater than zero it then stores a null
character into the next successive location of the array.
rdar://problem/35566567
Reviewers: EricWF, mclow.lists
Reviewed By: mclow.lists
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D40677
llvm-svn: 322326
test/support/msvc_stdlib_force_include.hpp
When testing MSVC's STL with C1XX, simulate a couple more compiler feature-test macros.
When testing MSVC's STL, simulate a few library feature-test macros.
test/std/atomics/atomics.lockfree/isalwayslockfree.pass.cpp
The vector_size attribute is a non-Standard extension that's supported by Clang and GCC,
but not C1XX. Therefore, guard this with `__has_attribute(vector_size)`.
Additionally, while these tests pass when MSVC's STL is compiled with Clang,
I don't consider this to be a supported scenario for our library,
so also guard this with defined(_LIBCPP_VERSION).
test/std/utilities/function.objects/func.not_fn/not_fn.pass.cpp
N4713 23.14.10 [func.not_fn]/1 depicts only `call_wrapper(call_wrapper&&) = default;`
and `call_wrapper(const call_wrapper&) = default;`. According to
15.8.2 [class.copy.assign]/2 and /4, this makes call_wrapper non-assignable.
Therefore, guard the assignability tests as libc++ specific.
Add a (void) cast to tolerate not_fn() being marked as nodiscard.
Fixes D41213.
llvm-svn: 322144
Summary:
After rL319736 for D28253 (which fixes PR28929), gcc cannot compile `<memory>` anymore in pre-C+11 modes, complaining:
```
In file included from /usr/include/c++/v1/memory:648:0,
from test.cpp:1:
/usr/include/c++/v1/memory: In static member function 'static std::__1::shared_ptr<_Tp> std::__1::shared_ptr<_Tp>::make_shared(_A0&, _A1&, _A2&)':
/usr/include/c++/v1/memory:4365:5: error: wrong number of template arguments (4, should be at least 1)
static_assert((is_constructible<_Tp, _A0, _A1, _A2>::value), "Can't construct object in make_shared" );
^
In file included from /usr/include/c++/v1/memory:649:0,
from test.cpp:1:
/usr/include/c++/v1/type_traits:3198:29: note: provided for 'template<class _Tp, class _A0, class _A1> struct std::__1::is_constructible'
struct _LIBCPP_TEMPLATE_VIS is_constructible
^~~~~~~~~~~~~~~~
In file included from /usr/include/c++/v1/memory:648:0,
from test.cpp:1:
/usr/include/c++/v1/memory:4365:5: error: template argument 1 is invalid
static_assert((is_constructible<_Tp, _A0, _A1, _A2>::value), "Can't construct object in make_shared" );
^
/usr/include/c++/v1/memory: In static member function 'static std::__1::shared_ptr<_Tp> std::__1::shared_ptr<_Tp>::allocate_shared(const _Alloc&, _A0&, _A1&, _A2&)':
/usr/include/c++/v1/memory:4444:5: error: wrong number of template arguments (4, should be at least 1)
static_assert((is_constructible<_Tp, _A0, _A1, _A2>::value), "Can't construct object in allocate_shared" );
^
In file included from /usr/include/c++/v1/memory:649:0,
from test.cpp:1:
/usr/include/c++/v1/type_traits:3198:29: note: provided for 'template<class _Tp, class _A0, class _A1> struct std::__1::is_constructible'
struct _LIBCPP_TEMPLATE_VIS is_constructible
^~~~~~~~~~~~~~~~
In file included from /usr/include/c++/v1/memory:648:0,
from test.cpp:1:
/usr/include/c++/v1/memory:4444:5: error: template argument 1 is invalid
static_assert((is_constructible<_Tp, _A0, _A1, _A2>::value), "Can't construct object in allocate_shared" );
^
```
This is also reported in https://bugs.freebsd.org/224946 (FreeBSD is apparently one of the very few projects that regularly builds programs against libc++ with gcc).
The reason is that the static assertions are invoking `is_constructible` with three arguments, while gcc does not have the built-in `is_constructible` feature, and the pre-C++11 `is_constructible` wrappers in `<type_traits>` only provide up to two arguments.
I have added additional wrappers for three arguments, modified the `is_constructible` entry point to take three arguments instead, and added a simple test to is_constructible.pass.cpp.
Reviewers: EricWF, mclow.lists
Reviewed By: EricWF
Subscribers: krytarowski, cfe-commits, emaste
Differential Revision: https://reviews.llvm.org/D41805
llvm-svn: 321963
Reviewed as https://reviews.llvm.org/D41748
* These tests use function objects from functional, back_inserter from iterator, and equal from algorithm, so add those headers.
* The use of iota targeting vector<unsigned char> with an int parameter triggers warnings on MSVC++ assigning an into a unsigned char&; so change the parameter to unsigned char with a static_cast.
* Avoid naming unary_function in identity here as that is removed in '17. (This also fixes naming _VSTD, _NOEXCEPT_, and other libcxx-isms)
* Change the predicate in the transform tests to add_ten so that problems with multiple application are caught.
llvm-svn: 321922
* _VSTD should be std.
* <utility> is needed for forward.
* unary_function is no longer standard (and unnecessary for this, a C++17-only test)
llvm-svn: 321847
As a result of this change, the basic_stringbuf constructor that
takes a mode ends up leaving __hm_ set to 0, causing the comparison
"__hm_ - __str_.data() < __noff" in seekoff() to succeed, which caused
the function to incorrectly return -1. The fix is to account for the
possibility of __hm_ being 0 when computing the distance from __hm_
to the start of the string.
Differential Revision: https://reviews.llvm.org/D41319
llvm-svn: 321124
Summary:
[libcxx] Fix basic_stringbuf constructor
The C++ Standard [stringbuf.cons]p1 defines the effects of the basic_stringbuf
constructor that takes ios_base::openmode as follows:
Effects: Constructs an object of class basic_stringbuf, initializing the
base class with basic_streambuf(), and initializing mode with which.
Postconditions: str() == "".
The default constructor of basic_streambuf shall initialize all its
pointer member objects to null pointers [streambuf.cons]p1.
Currently libc++ calls "str(string_type());" in the aforementioned constructor
setting basic_streambuf's pointers to a non-null value.
This patch removes the call (note that the postcondition str() == ""
remains valid because __str_ is default-initialized) and adds a test checking
that the basic_streambuf's pointers are null after construction.
Thanks Mikhail Maltsev for the patch.
Reviewers: EricWF, mclow.lists
Reviewed By: mclow.lists
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D40707
llvm-svn: 320604
benchmarks/util_smartptr.bench.cpp
Change CRLF to LF.
test/std/localization/locale.categories/category.monetary/locale.money.get/locale.money.get.members/get_long_double_fr_FR.pass.cpp
Consistently comment "\u20ac" as EURO SIGN, its Unicode name, instead of the actual Unicode character.
test/std/utilities/allocator.adaptor/allocator.adaptor.members/construct_type.pass.cpp
Avoid non-ASCII dash.
Fixes D40991.
llvm-svn: 320536
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
Summary:
Introduce a new form of `result_of` without function type encoding.
Rename and split `is_callable/is_nothrow_callable` into `is_invocable/is_nothrow_invocable/is_invocable_r/is_nothrow_invocable_r` (and associated types accordingly)
Change function type encoding of previous `is_callable/is_nothrow_callable` traits to conventional template type parameter lists.
Reviewers: EricWF, mclow.lists, bebuch
Reviewed By: EricWF, bebuch
Subscribers: lichray, bebuch, cfe-commits
Differential Revision: https://reviews.llvm.org/D38831
llvm-svn: 320509
Currently libc++ defines operator== and operator!= as friend functions in the
definition of the istream_iterator class template. Such definition has a subtle
difference from an out-of-line definition required by the C++ Standard: these
functions can only be found by argument-dependent lookup, but not by qualified
lookup.
This patch changes the definition, so that it conforms to the C++ Standard and
adds a check involving qualified lookup to the test suite.
Patch contributed by Mikhail Maltsev.
Differential Revision: https://reviews.llvm.org/D40415
llvm-svn: 320363
AddLLVM is needed for several functions that are used in tests and
as such needs to be included from the right context which previously
wasn't the case.
Differential Revision: https://reviews.llvm.org/D40280
llvm-svn: 319515
r318862 added a fix for 0-termination input array in case of an error. Previous
libcxx versions don't have the fix and corresponding tests should be failing.
llvm-svn: 318863
It covers the cases when the sentry object returns false and when an exception
was thrown. Corresponding standard paragraph is C++14 [istream.unformatted]p21:
In any case, if n is greater than zero, it then stores a null character
(using charT()) into the next successive location of the array.
Patch by Reimar Döffinger.
llvm-svn: 318862
In a17cd7c641c34b6c4bd4845a4d4fb590cb6c238c Marshall added assert(true) to the vector<bool>::size tests, which break on C1XX:
D:\Contest\gl0qojfu.5pe\src\qa\vc\libs\libcxx\upstream\test\std\containers\sequences\vector.bool\size.pass.cpp(62): error C2220: warning treated as error - no 'object' file generated
d:\contest\gl0qojfu.5pe\src\qa\vc\libs\libcxx\upstream\test\std\containers\sequences\vector.bool\size.pass.cpp(33) : warning C6326: Potential comparison of a constant with another constant.
d:\contest\gl0qojfu.5pe\src\qa\vc\libs\libcxx\upstream\test\std\containers\sequences\vector.bool\size.pass.cpp(52) : warning C6326: Potential comparison of a constant with another constant.
The corresponding test for vector::size asserts assert(c.size() == 3);, so I changed it to do that here.
llvm-svn: 318812
Summary:
Currently `std::variant` always uses an unsigned int to store the variant index. However this isn't nessesary and causes `std::variant` to be larger than it needs to be in most cases.
This patch changes the index type to be `unsigned char` when possible, and `unsigned short` or `unsigned int` otherwise, depending on the size (Although it's questionable if it's even possible to create a variant with 65535 elements.
Unfortunately this change is an ABI break, and as such is only enabled in ABI v2.
Reviewers: mpark
Reviewed By: mpark
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D40210
llvm-svn: 318621
Summary:
In the CHERI clang compiler __output and __input are keywords and therefore
we can't compile libc++ with our compiler.
Reviewers: mclow.lists, EricWF, theraven
Reviewed By: EricWF
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D39537
llvm-svn: 318144
r313500 added a fix for undefined "___cxa_deleted_virtual" symbol.
Previous libcxx versions don't have the fix and corresponding test
should be failing.
rdar://problem/34521053
Reviewers: EricWF, mclow.lists, ahatanak
Reviewed By: ahatanak
Subscribers: mehdi_amini, cfe-commits
Differential Revision: https://reviews.llvm.org/D39776
llvm-svn: 317734
This patch changes the test suite to attempt and prefer -std=c++17 over
-std=c++1z. It also fixes the REQUIRES and UNSUPPORTED lit markers
to refer to c++17 over c++1z.
llvm-svn: 317610
LWG 3013 points out that the constructors and increment members
of the directory iterators need to allocate, and therefore cannot
be marked noexcept.
It also points out that `is_empty` and `copy` likely need to allocate
as well, and as such can also not be noexcept.
This patch speculatively implements the resolution removing noexcept,
because libc++ does indeed have the possibility of throwing on allocation
failure.
llvm-svn: 316941
The guts of the increment method for recursive_directory_iterator
was failing to pass an error code object to calls to status/symlink_status,
which can throw under certain conditions.
This patch fixes the issues by correctly propagating the error codes.
However the noexcept still needs to be removed from the signature, as
mentioned in LWG 3014, but that change will be made in a separate commit.
llvm-svn: 316939
Summary:
The constructors `vector(Iter, Iter, Alloc = Alloc{})` and `assign(Iter, Iter)` don't correctly perform EmplaceConstruction from the result of dereferencing the iterator. This results in them performing an additional and unneeded copy.
This patch addresses the issue by correctly using `emplace_back` in C++11 and newer.
There are also some bugs in our `insert` implementation, but those will be handled separately.
@mclow.lists We should probably merge this into 5.1, agreed?
Reviewers: mclow.lists, dlj, EricWF
Reviewed By: mclow.lists, EricWF
Subscribers: cfe-commits, mclow.lists
Differential Revision: https://reviews.llvm.org/D38757
llvm-svn: 315994
The vcruntime headers are hairy and clash with both libc++ headers
themselves and other libraries. libc++ normally deals with the clashes
by deferring to the vcruntime headers and silencing its own definitions,
but for clients which don't want to depend on vcruntime headers, it's
desirable to support the opposite, i.e. have libc++ provide its own
definitions.
Certain operator new/delete replacement scenarios are not currently
supported in this mode, which requires some tests to be marked XFAIL.
The added documentation has more details.
Differential Revision: https://reviews.llvm.org/D38522
llvm-svn: 315234
This warning "structure was padded due to alignment specifier" says
that the compiler is going to do exactly what you asked it to do.
It's triggered by the tests for over-aligned dynamic memory allocation.
llvm-svn: 314257
After speaking with the libcxx owners, they agreed that this is
a bug in the bot that needs to be fixed by the bot owners, and
the CMake changes are correct.
llvm-svn: 313643
This reverts commit 4ad71811d45268d81b60f27e3b8b2bcbc23bd7b9.
There is a bot that is checking out libcxx and lit with nothing
else and then running lit.py against the test tree. Since there's
no LLVM source tree, there's no LLVM CMake. CMake actually
reports this as a warning saying unsupported libcxx configuration,
but I guess someone is depending on it anyway.
llvm-svn: 313607
Patch from Eddie Elizondo. Reviewed as D37830 (https://reviews.llvm.org/D37830).
On MacOSX the following program:
struct S { virtual void f() = delete; };
int main() { new S; }
Fails with the following error:
Undefined symbols for architecture x86_64:
"___cxa_deleted_virtual"
This adds a fix to export the needed symbols.
Test:
> lit -sv test/libcxx/language.support/cxa_deleted_virtual.pass.cpp
> Testing Time: 0.21s
> Expected Passes : 1
llvm-svn: 313500
Clang recently changed the way it outputs static assert diagnostics.
This patch fixes libc++'s -verify tests so they tolerate both the old
and new message format.
llvm-svn: 313499
There were a number of cases where __double_underscore functions,
for example __has_construct_test, were called without being qualified,
causing ADL to occur. This patch qualifies those calls to avoid this
problem.
Thanks to David L. Jones for point out the issue initially.
llvm-svn: 313324
This patch fixes llvm.org/PR34298. Previously libc++ incorrectly evaluated
the __invokable trait via the converting constructor `function(Tp)` [with Tp = std::function]
whenever the copy constructor or copy assignment operator
was required. This patch further constrains that constructor to short
circut before evaluating the troublesome SFINAE when `Tp` matches
std::function.
The original patch is from Alex Lorenz.
llvm-svn: 312892
This reverts commit r312890 because the test case fails to compile for
older versions of Clang that reject initializing a const object without
a user defined constructor.
Since this patch should go into 5.0.1, I want to keep it an atomic change,
and will re-commit it with a fixed test case.
llvm-svn: 312891
This patch fixes llvm.org/PR34298. Previously libc++ incorrectly evaluated
the __invokable trait via the converting constructor `function(Tp)` [with Tp = std::function]
whenever the copy constructor or copy assignment operator
was required. This patch further constrains that constructor to short
circut before evaluating the troublesome SFINAE when `Tp` matches
std::function.
The original patch is from Alex Lorenz.
llvm-svn: 312890
* Update specification text from N4387
* Delete not_brace_initializable.fail.cpp: it's redundant with nullopt_t.fail.cpp
* is_empty<T> implies is_class<T>
* is_literal is deprecated; directly verify that we can create a nullopt_t in a constexpr context
Differential Revision: D37024
llvm-svn: 312256
test/std/containers/Emplaceable.h
test/std/containers/NotConstructible.h
test/support/counting_predicates.hpp
Replace unary_function/binary_function inheritance with typedefs.
test/std/depr/depr.function.objects/depr.base/binary_function.pass.cpp
test/std/depr/depr.function.objects/depr.base/unary_function.pass.cpp
test/std/utilities/function.objects/func.require/binary_function.pass.cpp
test/std/utilities/function.objects/func.require/unary_function.pass.cpp
Mark these tests as requiring 98/03/11/14 because 17 removed unary_function/binary_function.
test/std/thread/futures/futures.task/futures.task.members/ctor_func_alloc.pass.cpp
test/std/thread/futures/futures.task/futures.task.nonmembers/uses_allocator.pass.cpp
Mark these tests as requiring 11/14 because 17 removed packaged_task allocator support.
test/std/utilities/function.objects/func.wrap/func.wrap.func/derive_from.pass.cpp
This test doesn't need to be skipped in C++17 mode. Only the construction of
std::function from an allocator needs to be skipped in C++17 mode.
test/std/utilities/function.objects/refwrap/refwrap.access/conversion.pass.cpp
test/std/utilities/function.objects/refwrap/refwrap.assign/copy_assign.pass.cpp
test/std/utilities/function.objects/refwrap/refwrap.const/copy_ctor.pass.cpp
test/std/utilities/function.objects/refwrap/refwrap.const/type_ctor.pass.cpp
When testing these reference_wrapper features, unary_function inheritance is totally irrelevant.
test/std/utilities/function.objects/refwrap/weak_result.pass.cpp
Define and use my_unary_function/my_binary_function to test the weak result type machinery
(which is still present in C++17, although deprecated).
test/support/msvc_stdlib_force_include.hpp
Now we can test C++17 strictly, without enabling removed features.
Fixes D36503.
llvm-svn: 311705
This improves readability and (theoretically) improves portability,
as _Ugly names are reserved.
This performs additional de-uglification, so all of these tests
follow the example of iterator.traits/empty.pass.cpp.
llvm-svn: 310761
This makes them consistent (many comments already used uppercase).
The special REQUIRES, UNSUPPORTED, and XFAIL comments are excluded from this change.
llvm-svn: 309468
Creating a function pointer with proper parameters pointing to std::next() or std::prev() should work.
This change moves the invented paramater for enable_if over to the return type to resolve this QoI issue.
Patch by Jason Liu.
Differential Revision: https://reviews.llvm.org/D34649
llvm-svn: 308932
On Apple the test feature 'sanitizer-new-delete' was incorrectly
getting added to the LIT feature set, which mistakenly caused tests
to be disabled when using UBSAN (the feature is only needed with ASAN/MSAN/TSAN).
llvm-svn: 307518
32-bit powerpc provides a 64 bit time_t type and older ppc64 systems
provide time_t as a floating point type. This caused problems when building
operations.cpp since operations.cpp contained compile time tests for conversions
between time_t and filesystem time type.
When these tests failed they caused the libc++ build to fail as well. This is unfortunate.
This patch moves the tests out of the source file and into the test suite. It also
expands the tests to allow testing of the weird time_t configurations on all platforms.
llvm-svn: 307461
r283051 added some functions to cmath (in namespace std) that have the
same name as functions in math.h (in the global namespace). Clang's
limited support for `-fdelayed-template-parsing` chokes on this. Rename
the ones in `cmath` and their uses in `complex` and the test.
rdar://problem/32848355
llvm-svn: 307357
In order for IDE's like CLion to correctly parse and highlight the tests
it needs to know roughly how to build them. This patch adds a dummy CMake target
for each/all of the .pass.cpp tests in the test suite to solve this problem.
The target is only created when LIBCXX_CONFIGURE_IDE=ON, so it shouldn't affect
most users.
Originally I wasn't sure that this change deserved to live upstream, but it's
quite frustrating to edit libc++ tests using CLion or Visual Studio without it,
in particular the filesystem tests which rely heavily on macros. Even though the change
should have no effect on non-IDE users/configurations I decided to commit it upstream
with the hopes it will benefit somebody other than me.
llvm-svn: 307118
This patch speculatively implements the PR for LWG 2937, which fixes
two issues with equivalent.
(1) It makes equivalent("dne", "exists") an error. Previously only
equivalent("dne", "dne") was an error and the former case was not (it returned false).
Now equivalent reports an error when either input doesn't exist.
(2) It makes equivalent(p1, p2) well-formed when `is_other(p1) && is_other(p2)`.
Previously this was an error, but there is seemingly no reason why it should be on POSIX system.
llvm-svn: 307117
This reverts commit r306310.
r306310 causes clang to reject a call to an aligned allocation or
deallocation function if it is not implemented in the standard library
of the deployment target. This is not the desired behavior when users
have defined their own aligned functions.
rdar://problem/32664169
llvm-svn: 306859
attribute.
This is needed because older versions of libc++ do not have these
operators. If users target an older deployment target and try to compile
programs in which these operators are explicitly called, the compiler
will complain.
The following is the list of minimum deployment targets for the four
OSes:
macosx: 10.13
ios: 11.0
tvos: 11.0
watchos: 4.0
rdar://problem/32664169
Differential Revision: https://reviews.llvm.org/D34556
llvm-svn: 306310
Clang and C1XX both complain about mismatched class/struct, but libc++ and MSVC's STL
differ on what they use for tuple_element/tuple_size, so there's no way to win here.
I'm reverting this part of my previous change. In the future, I'll have to suppress
the warning for one compiler or the other.
llvm-svn: 305854
Style/paranoia: 42.1 doesn't have an exact binary representation. Although this doesn't
cause failures, it makes me uncomfortable, so I'm changing it to 42.5.
C1XX rightly warns about unreferenced variables. Adding tests for their values
makes C1XX happy and improves test coverage.
C1XX (somewhat obnoxiously) warns about seeing a struct specialized as a class.
Although the Standard doesn't care, saying struct consistently is better.
(The Standard itself is still inconsistent about whether to depict tuple_element
and tuple_size as structs or classes.)
Fixes D33953.
llvm-svn: 305843
Remarks: This function shall not participate in overload resolution unless
`is_same_v<decay_t<T>, variant>` is false, unless `decay_t<T>` is
neither a specialization of `in_place_type_t` nor a specialization of
`in_place_index_t`, unless `is_constructible_v<Tj, T>` is true, and
unless the expression `FUN(std::forward<T>(t))` (with `FUN` being the
above-mentioned set of imaginary functions) is well formed.
Depends on D34111.
Reviewers: EricWF, K-ballo
Reviewed By: EricWF
Subscribers: fhahn
Differential Revision: https://reviews.llvm.org/D34112
llvm-svn: 305668
C99 at least. C89 still fails due to the use of block comments.
NOTE: Having libc++ on the include path when compiling C is not
recommended or ever really supported. However it happens often
enough that this change is warrented.
llvm-svn: 305539
It seems conceivable that a user would need to get a coroutine handle
having only a const reference to the promise_type, for example from
within a const member function of the promise.
This patch allows that use case. A coroutine_handle<const T> can be used
in essentially the same way a coroutine_handle<T>, ie to start and destroy
the coroutine. The constness of the promise doesn't/shouldn't propagate
to the handle.
llvm-svn: 305536
