Makes libc++ behavior consistent between C++03 and C++11.
Can use `decltype` in C++03 because `include/__config` defines a macro when
`decltype` is not available.
Reviewers: mclow.lists, EricWF, erik.pilkington, ldionne
Reviewed By: ldionne
Subscribers: dexonsmith, cfe-commits, howard.hinnant, ldionne, christof, jkorous, Quuxplusone
Differential Revision: https://reviews.llvm.org/D48753
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@349676 91177308-0d34-0410-b5e6-96231b3b80d8
Explicitly disable the -Wformat-zero-length diagnostic when running
ctime tests, since one of the test cases passes zero-length format
string to strftime(). When strftime() is appropriately decorated
with __attribute__(format, ...), this caused the test to fail because
of this warning (e.g. on NetBSD).
Differential Revision: https://reviews.llvm.org/D55661
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@349294 91177308-0d34-0410-b5e6-96231b3b80d8
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
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@348847 91177308-0d34-0410-b5e6-96231b3b80d8
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
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@348824 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@348520 91177308-0d34-0410-b5e6-96231b3b80d8
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
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@348138 91177308-0d34-0410-b5e6-96231b3b80d8
This reverts commit 087f065cb0.
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.
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@347816 91177308-0d34-0410-b5e6-96231b3b80d8
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
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@347787 91177308-0d34-0410-b5e6-96231b3b80d8
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
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@347568 91177308-0d34-0410-b5e6-96231b3b80d8
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).
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@347264 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@347232 91177308-0d34-0410-b5e6-96231b3b80d8
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
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@346764 91177308-0d34-0410-b5e6-96231b3b80d8
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
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@345148 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@344580 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@342854 91177308-0d34-0410-b5e6-96231b3b80d8
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
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@342843 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@342560 91177308-0d34-0410-b5e6-96231b3b80d8
