| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
| |
llvm-svn: 343435
|
|
|
|
| |
llvm-svn: 343432
|
|
|
|
|
|
| |
Tested on Docker containers with Clang 4, 5 and 6.
llvm-svn: 342855
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
| |
llvm-svn: 342821
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
| |
llvm-svn: 342818
|
|
|
|
|
|
|
|
| |
test
libcxx-libcxxabi-x86_64-linux-ubuntu-asan complains about a leak here.
llvm-svn: 342814
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
pre-C++2a [[nodiscard]]
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
|
|
|
|
| |
llvm-svn: 342609
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
https://reviews.llvm.org/D44263
llvm-svn: 342566
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
| |
llvm-svn: 342524
|
|
|
|
| |
llvm-svn: 342103
|
|
|
|
|
|
| |
feature test macros, though. Reviewed as: https://reviews.llvm.org/D51955
llvm-svn: 342073
|
|
|
|
|
|
| |
extra tests.
llvm-svn: 342070
|
|
|
|
|
|
| |
underlying abi library on some Mac OS versions does not support the plural uncaught_exceptions, so libc++ emulates it from the singlar; this means it will only return 0 or 1.
llvm-svn: 342063
|
|
|
|
| |
llvm-svn: 342057
|
|
|
|
|
|
| |
were not constexpr. I looked, and they were right. They were made constexpr in p0505, so I looked at all the other bits in that paper to make sure that I didn't miss anything else. There were a couple methods in the synopsis that should have been marked constexpr, but the code was correct.
llvm-svn: 340992
|
|
|
|
|
|
| |
drive-by, make the same change in raw_storage_iterator (twice).
llvm-svn: 340823
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
tests for all the containers that have clear().
llvm-svn: 340385
|
|
|
|
|
|
| |
https://reviews.llvm.org/D50815 - with a fix for the sanitizer bots
llvm-svn: 340045
|
|
|
|
|
|
|
|
|
|
| |
https://reviews.llvm.org/D50815"
Breaks build on sanitizer bots.
This reverts commit r339943.
llvm-svn: 339971
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
| |
llvm-svn: 339943
|
|
|
|
|
|
| |
don't have it. Reviewed as https://reviews.llvm.org/D50799
llvm-svn: 339816
|
|
|
|
|
|
| |
since those calls were introduced in C++11. They're already guarded by an ifdef in the code, so this is a 'belt-and-suspenders' change.
llvm-svn: 339804
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
<charconv> was added in r338479. Previous libcxx versions don't have
this functionality and corresponding tests should be failing.
Reviewers: mclow.lists, ldionne, EricWF
Reviewed By: ldionne
Subscribers: christof, dexonsmith, lichray, EricWF, cfe-commits
Differential Revision: https://reviews.llvm.org/D50543
llvm-svn: 339451
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
of standard
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
|
|
|
|
| |
llvm-svn: 339218
|
|
|
|
|
|
|
|
| |
istream.rvalue/rvalue.pass.cpp
(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
|
|
|
|
|
|
|
|
|
|
| |
basic.ios.members/narrow.pass.cpp
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
|
|
|
|
|
|
|
|
| |
by <bitset>
Reviewed as https://reviews.llvm.org/D50421
llvm-svn: 339212
|
|
|
|
|
|
| |
Reviewed as https://reviews.llvm.org/D50420
llvm-svn: 339209
|
|
|
|
|
|
| |
tests to ensure that we continue to DTRT.
llvm-svn: 338936
|
|
|
|
| |
llvm-svn: 338803
|
|
|
|
|
|
| |
the test_comparison routines that I committed last week. NFC.
llvm-svn: 338797
|