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
In addition to the PR for LWG 2773 this patch also ensures
that each of std::ignores constructors or assignment operators
are constexpr.
llvm-svn: 294165
The test was previously set to XFAIL if __cpp_structured_bindings
wasn't defined. However there are Clang 4.0 versions which do not
define this macro but do provide structured bindings, which causes
the test to pass unexpectedly.
This patch changes the XFAIL to an UNSUPPORTED.
llvm-svn: 291060
Summary:
This patch attempts to re-implement a fix for LWG 2770, but not the actual specified PR.
The PR for 2770 specifies tuple_size<T const> as only conditionally providing a `::value` member. However C++17 structured bindings require `tuple_size<T const>` to be complete only if `tuple_size<T>` is also complete. Therefore this patch implements only provides the specialization `tuple_size<T CV>` iff `tuple_size<T>` is a complete type.
This fixes http://llvm.org/PR31513.
Reviewers: mclow.lists, rsmith, mpark
Subscribers: mpark, cfe-commits
Differential Revision: https://reviews.llvm.org/D28222
llvm-svn: 291019
This patch implements the correct PR for LWG 2770. It also makes the primary
tuple_size template incomplete again which fixes part of llvm.org/PR31513.
llvm-svn: 290846
This patch reverts the changes to tuple which fixed construction from
types derived from tuple. It breaks the code mentioned in llvm.org/PR31384.
I'll follow this commit up with a test case.
llvm-svn: 289773
Summary:
The standard requires tuple have the following constructors:
```
tuple(tuple<OtherTypes...> const&);
tuple(tuple<OtherTypes...> &&);
tuple(pair<T1, T2> const&);
tuple(pair<T1, T2> &&);
tuple(array<T, N> const&);
tuple(array<T, N> &&);
```
However libc++ implements these as a single constructor with the signature:
```
template <class TupleLike, enable_if_t<__is_tuple_like<TupleLike>::value>>
tuple(TupleLike&&);
```
This causes the constructor to reject types derived from tuple-like types; Unlike if we had all of the concrete overloads, because they cause the derived->base conversion in the signature.
This patch fixes this issue by detecting derived types and the tuple-like base they are derived from. It does this by creating an overloaded function with signatures for each of tuple/pair/array and checking if the possibly derived type can convert to any of them.
This patch fixes [PR17550]( https://llvm.org/bugs/show_bug.cgi?id=17550)
This patch
Reviewers: mclow.lists, K-ballo, mpark, EricWF
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D27606
llvm-svn: 289727
test/support/test_macros.h
For convenience/greppability, add macros for libcxx-specific static_asserts about noexceptness.
(Moving the definitions of ASSERT_NOEXCEPT/ASSERT_NOT_NOEXCEPT isn't technically necessary
because they're macros, but I think it's better style to define stuff before using it.)
test/std/utilities/tuple/tuple.tuple/tuple.apply/apply.pass.cpp
There was a completely unused `TrackedCallable obj;`.
apply() isn't depicted with conditional noexcept in C++17.
test/std/utilities/tuple/tuple.tuple/tuple.apply/make_from_tuple.pass.cpp
Now that we have LIBCPP_ASSERT_NOEXCEPT, use it.
Fixes D27622.
llvm-svn: 289264
This patch removes libc++'s tuple extension which allowed it to be
constructed from fewer initializers than elements; with the remaining
elements being default constructed. However the implicit version of
this extension breaks conforming code. For example:
int fun(std::string);
int fun(std::tuple<std::string, int>);
int x = fun("hello"); // ambigious
Because existing code may already depend on this extension it can be re-enabled
by defining _LIBCPP_ENABLE_TUPLE_IMPLICIT_REDUCED_ARITY_EXTENSION.
Note that the explicit version of this extension is still supported,
although it's somewhat less useful than the implicit one.
llvm-svn: 289158
Instead of storing double in double and then truncating to int, store int in long
and then widen to long long. This preserves test coverage (as these tests are
interested in various tuple conversions) while avoiding truncation warnings.
test/std/utilities/tuple/tuple.tuple/tuple.cnstr/const_pair.pass.cpp
Since we aren't physically truncating anymore, t1 is equal to p0.
test/std/utilities/tuple/tuple.tuple/tuple.cnstr/convert_copy.pass.cpp
One edit is different from the usual pattern. Previously, we were storing
double in double and then converting to A, which has an implicitly converting
constructor from int. Now, we're storing int in int and then converting to A,
avoiding the truncation.
Fixes D27542.
llvm-svn: 289109
Change char to long and remove some char casts. This preserves test coverage for tuple's
heterogeneous comparisons, while avoiding int-to-char truncation warnings.
Fixes D27541.
llvm-svn: 289108
This replaces every occurrence of _LIBCPP_STD_VER in the tests with
TEST_STD_VER. Additionally, for every affected
file, #include "test_macros.h" is being added explicitly if it wasn't
already there.
https://reviews.llvm.org/D26294
llvm-svn: 286007
This is a breaking change. The SFINAE required is instantiated the second
the class is instantiated, and this can cause hard SFINAE errors
when applied to references to incomplete types. Ex.
struct IncompleteType;
extern IncompleteType it;
std::tuple<IncompleteType&> t(it); // SFINAE will blow up.
llvm-svn: 276598
This patch upgrades <tuple> to be C++17 compliant by implementing:
* tuple_size_v: This was forgotten when implementing the other _v traits.
* std::apply: This was added via LFTS v1 in p0220r1.
* std::make_from_tuple: This was added in p0209r2.
llvm-svn: 275745
This patch attempts to improve the QoI of std::tuples tuple_element and
__make_tuple_types helpers. Previously they required O(N) instantiations,
one for every element in the tuple
The new implementations are O(1) after __tuple_indices<Id...> is created.
llvm-svn: 274330
Libc++ has to deduce the 'allocator_arg_t' parameter as 'AllocArgT' for the
following constructor:
template <class Alloc> tuple(allocator_arg_t, Alloc const&)
Previously libc++ has tried to support tags derived from 'allocator_arg_t' by
using 'is_base_of<AllocArgT, allocator_arg_t>'. However this breaks whenever a
2-tuple contains a reference to an incomplete type as its first parameter.
See https://llvm.org/bugs/show_bug.cgi?id=27684
llvm-svn: 273334
Quite a few libcxx tests seem to follow the format:
#if _LIBCPP_STD_VER > X
// Do test.
#else
// Empty test.
#endif
We should instead use the UNSUPPORTED lit directive to exclude the test on
earlier C++ standards. This gives us a more accurate number of test passes
for those standards and avoids unnecessary conflicts with other lit
directives on the same tests.
Reviewers: bcraig, ericwf, mclow.lists
Differential revision: http://reviews.llvm.org/D20730
llvm-svn: 271108
