Commit Graph

84 Commits

Author SHA1 Message Date
Eric Fiselier baaee20690 Add tests for class template deduction on std::tuple.
llvm-svn: 304967
2017-06-08 07:18:17 +00:00
Eric Fiselier def3c375e0 Rename unreserved names in tuple
llvm-svn: 304382
2017-06-01 02:14:21 +00:00
Eric Fiselier 2987087182 Cleanup remaining usages of _LIBCPP_HAS_NO_<c++11-feature> in tuple and utility
llvm-svn: 300644
2017-04-19 01:23:39 +00:00
Eric Fiselier 9af60c4a8b Implement LWG 2773 - std::ignore should be constexpr.
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
2017-02-06 01:25:31 +00:00
Eric Fiselier 5ddaeb888d Fix inconsistency in tuple's SFINAE. Patch from Andrey Khalyavin"
llvm-svn: 294106
2017-02-04 22:57:01 +00:00
Eric Fiselier b43f17c835 Fix std::tuples EBO when targeting the MSVC ABI.
MSVC/clang-cl doesn't do a full EBO unless __declspec(empty_bases)
is applied to the derived type. This causes certain tuple tests
to fail.

This patch adds the empty_bases attribute to __tuple_impl in order
for tuple to fully provide the EBO.

llvm-svn: 292159
2017-01-16 21:15:08 +00:00
Eric Fiselier e2f2d1edef [NFC] Rename _LIBCPP_TYPE_VIS_ONLY to _LIBCPP_TEMPLATE_VIS
The name _LIBCPP_TYPE_VIS_ONLY is no longer accurate because both
_LIBCPP_TYPE_VIS and _LIBCPP_TYPE_VIS_ONLY expand to
__attribute__((__type_visibility__)) with Clang. The only remaining difference
is that _LIBCPP_TYPE_VIS_ONLY can be applied to templates whereas
_LIBCPP_TYPE_VIS cannot (due to dllimport/dllexport not being allowed on
templates).

This patch renames _LIBCPP_TYPE_VIS_ONLY to _LIBCPP_TEMPLATE_VIS.

llvm-svn: 291035
2017-01-04 23:56:00 +00:00
Eric Fiselier 1013fe3c0c Re-implement LWG 2770 - Fix tuple_size with structured bindings.
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
2017-01-02 23:54:13 +00:00
Eric Fiselier 347a1cc221 Revert r289727 due to PR31384
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
2016-12-15 06:34:54 +00:00
Eric Fiselier f8136d08c6 [libcxx] Fix tuple construction/assignment from types derived from tuple/pair/array.
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
2016-12-14 22:22:38 +00:00
Eric Fiselier bd688258ba Fix PR27374 - Remove the implicit reduced-arity-extension in tuple.
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
2016-12-08 23:57:08 +00:00
Eric Fiselier 2371589266 Implement LWG 2770 - Make tuple_size<T> defined for all T
llvm-svn: 286779
2016-11-13 20:43:50 +00:00
Eric Fiselier 40905833b5 Fix PR30979 - tuple<move_only> is constructible from move_only const&
llvm-svn: 286774
2016-11-13 19:54:31 +00:00
Eric Fiselier 4927c29577 Implement the std::pair parts of "Improving pair and tuple". Completes N4387.
llvm-svn: 276605
2016-07-25 04:32:07 +00:00
Eric Fiselier aedcbf898b Recommit r276548 - Make pair/tuples assignment operators SFINAE properly.
I think I've solved issues with is_assignable and references to incomplete
types. The updated patch adds tests for this case.

llvm-svn: 276603
2016-07-25 02:36:42 +00:00
Eric Fiselier 189f88ca35 Revert r276548 - Make pair/tuples assignment operators SFINAE properly.
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
2016-07-25 01:45:07 +00:00
Eric Fiselier 904a5d7007 Make pair/tuples assignment operators SFINAE properly.
llvm-svn: 276548
2016-07-24 05:51:11 +00:00
Eric Fiselier 074f8d7777 Add tests for reference binding assertions in std::tuple.
Libc++ provides static assertions to detect reference binding issues inside
tuple. This patch adds tests for those diagnostics.

It should be noted that these static assertions technically violate the
standard since it allows these illegal bindings to occur.

Also see https://llvm.org/bugs/show_bug.cgi?id=20855

llvm-svn: 276078
2016-07-20 02:57:39 +00:00
Eric Fiselier 03e29a2964 Implement C++17 tuple bits. Including apply and make_from_tuple.
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
2016-07-18 00:35:56 +00:00
Eric Fiselier 4f905b8daa Handle std::get<T>(...) for std::tuple<>
llvm-svn: 274422
2016-07-02 03:46:08 +00:00
Eric Fiselier f447e62e1d Rewrite std::get<Type>(...) helper using constexpr functions.
llvm-svn: 274418
2016-07-02 03:18:30 +00:00
Eric Fiselier e2fd8b8db9 Flatten tuple_constructible, tuple_convertible and tuple_assignable.
This patch is the last in a series that replaces recursive meta-programming
in std::tuple with non-recursive implementations.

Previously std::tuple could only be instantiated with 126 elements before
it blew the max template instantiation depth. Now the size of std::tuple is
essentially unbounded (I've tested with over 5000 elements).

One unfortunate side-effect of this change is that tuple_constructible
and similar no longer short circuit after the first failure. Instead they
evaluate the conditions for all elements. This could be potentially breaking.
I plan to look into this further.

llvm-svn: 274331
2016-07-01 04:07:39 +00:00
Eric Fiselier 092386771d Fix PR27684 - std::tuple no longer accepts reference to incomplete type in some cases.
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
2016-06-21 23:19:13 +00:00
Eric Fiselier 9795699a72 Make tuples constructors conditionally EXPLICIT. See N4387
llvm-svn: 266703
2016-04-19 01:19:25 +00:00
Eric Fiselier 74cba6427a Cleanup and guard tuple's constructor SFINAE. Fixes PR22806 and PR23256.
There are two main fixes in this patch.

First the constructor SFINAE was changed so that it's evaluated in two stages
where the first stage evaluates the "safe" SFINAE conditions and the second
evaluates the "dangerous" ones. The key is that the second stage is lazily
evaluated only if the first stage passes. This helps fix PR23256
(https://llvm.org/bugs/show_bug.cgi?id=23256).

The second fix is for PR22806 and LWG issue 2549. This fix applies
the suggested resolution to the LWG issue in order to prevent the construction
of dangling references. The SFINAE for this check is contained within
the _PreferTupleLikeConstructor alias template. The tuple-like constructors
are disabled whenever that trait returns false.

(https://llvm.org/bugs/show_bug.cgi?id=22806)
(http://cplusplus.github.io/LWG/lwg-active.html#2549)

llvm-svn: 266461
2016-04-15 18:05:59 +00:00
Eric Fiselier 90fb2baff7 [libcxx] Remove the "reduced-arity-initialization" extension from the uses-allocator constructors
Summary:
A default uses-allocator constructor has been added since that overload was previously provided by the extended constructor.

Since Clang does implicit conversion checking after substitution this constructor has to deduce the allocator_arg_t parameter so that it can prevent the evaluation of "is_default_constructible" if the first argument doesn't match. See http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#1391 for more information.

This patch fixes PR24779 (https://llvm.org/bugs/show_bug.cgi?id=24779)

Subscribers: cfe-commits

Differential Revision: http://reviews.llvm.org/D19006

llvm-svn: 266409
2016-04-15 03:29:40 +00:00
Eric Fiselier 545b8861fc [libcxx] LWG2485: get() should be overloaded for const tuple&&. Patch from K-Ballo.
Review: http://reviews.llvm.org/D14839
llvm-svn: 255941
2015-12-18 00:36:55 +00:00
Marshall Clow bfb3f2bf7d Fix some mistakes in the <utility> and <tuple> synopses. No functional change. Thannks to K-ballo for the patch
llvm-svn: 253593
2015-11-19 19:45:29 +00:00
Eric Fiselier ee187e247b [libcxx] Fix detection of __is_final.
Summary: Currently we only enable the use of __is_final(...) with Clang. GCC also provides __is_final(...) since 4.7 in all standard modes. This patch creates the macro _LIBCPP_HAS_IS_FINAL to note the availability of `__is_final`.

Reviewers: danalbert, mclow.lists

Reviewed By: mclow.lists

Subscribers: cfe-commits

Differential Revision: http://reviews.llvm.org/D8795

llvm-svn: 239664
2015-06-13 07:08:02 +00:00
Eric Fiselier ec6c06610f Remove unneeded redeclaration of reference_wrapper.
llvm-svn: 232887
2015-03-21 06:05:45 +00:00
Eric Fiselier 65500d4b29 [libc++] Try and prevent evaluation of `is_default_constructible` on tuples default constructor if it is not needed.
Summary:
Currently parts of the SFINAE on tuples default constructor always gets evaluated even when the default constructor is never called or instantiated. This can cause a hard compile error when a tuple is created with types that do not have a default constructor. Below is a self contained example using a pair like class. This code will not compile but probably should.

```

#include <type_traits>

template <class T>
struct IllFormedDefaultImp {
    IllFormedDefaultImp(T x) : value(x) {}
    constexpr IllFormedDefaultImp() {}
    T value;
};

typedef IllFormedDefaultImp<int &> IllFormedDefault;

template <class T, class U>
struct pair
{
  template <bool Dummy = true,
    class = typename std::enable_if<
         std::is_default_constructible<T>::value
      && std::is_default_constructible<U>::value
      && Dummy>::type
    >
  constexpr pair() : first(), second() {}

  pair(T const & t, U const & u) : first(t), second(u) {}

  T first;
  U second;
};

int main()
{
  int x = 1;
  IllFormedDefault v(x);
  pair<IllFormedDefault, IllFormedDefault> p(v, v);
}
```

One way to fix this is to use `Dummy` in a more involved way in the constructor SFINAE. The following patch fixes these sorts of hard compile errors for tuple.


Reviewers: mclow.lists, rsmith, K-ballo, EricWF

Reviewed By: EricWF

Subscribers: ldionne, cfe-commits

Differential Revision: http://reviews.llvm.org/D7569

llvm-svn: 230120
2015-02-21 02:30:41 +00:00
Duncan P. N. Exon Smith 53afae49ee tuple: Make operator<() linear instead of exponential
Patch by Matthew Dempsky!

llvm-svn: 226641
2015-01-21 02:51:17 +00:00
Eric Fiselier 53deb607d9 Fixes to get libc++ building on sun solaris. Patch from C Bergstrom.
llvm-svn: 222794
2014-11-25 21:57:41 +00:00
Marshall Clow 14c5ec5194 Fixes PR21157 'tuple: non-default constructible tuple hard failure' Thanks to Louis Dionne for the bug report and the patch.
llvm-svn: 219785
2014-10-15 10:33:02 +00:00
Marshall Clow 10a65e2ee1 Thanks to K-ballo for noting a second incorrect noexcept clause in tuple - and suggesting a more correct way to write the first
llvm-svn: 217884
2014-09-16 17:08:21 +00:00
Marshall Clow 3175f49d33 Fix a bad noexcept clause in tuple's move constructor
llvm-svn: 217878
2014-09-16 15:36:14 +00:00
Eric Fiselier 567bb79bf2 D4451: Fix copy/move issues casude by __tuple_leafs's converting constructor
llvm-svn: 213888
2014-07-24 18:48:34 +00:00
Marshall Clow f9af6140ff Some calls to get<>() were qualified. Some were not. Qualify them all. Fixes bug #20092. Thanks to Agustín Bergé for the bug report and the fix.
llvm-svn: 211563
2014-06-24 00:46:19 +00:00
Marshall Clow 7546a111a9 Default the copy and move constructors for __tuple_leaf. This fixes bugs 18853 and 19118. Add a test case for that.
llvm-svn: 206829
2014-04-21 23:48:09 +00:00
Marshall Clow 05c8dad230 Implement LWG Paper n3887: Consistent Metafunction Aliases. This adds std::tuple_element_t<> as an alias for tuple_element<>::type. Clean up the synopsis for tuple_element in <utility> as well.
llvm-svn: 202673
2014-03-03 06:18:11 +00:00
Marshall Clow 0d1560e10e Implement LWG issue 2301: Mark std::tie as constexpr
llvm-svn: 202158
2014-02-25 16:11:46 +00:00
Marshall Clow 0724bf6767 Rename ___make_pair_return to __make_pair_return_impl; ___make_tuple_return to __make_tuple_return_impl; and ____iterator_traits to __iterator_traits_impl. Part of a campaign to remove > 2 underscores from libc++. No functionality change.
llvm-svn: 198457
2014-01-03 22:55:49 +00:00
Howard Hinnant 4478b25ade Fix several tuple bugs that were exposed by clang's implementation of CWG 1402. This fixes http://llvm.org/bugs/show_bug.cgi?id=17798.
llvm-svn: 194154
2013-11-06 17:45:43 +00:00
Marshall Clow de9320aa2b Implement LWG issue 2275 'forward_as_tuple should be constexpr'
llvm-svn: 192038
2013-10-05 18:46:37 +00:00
Marshall Clow ad864049d6 Remove non-printable chars that snuck in back in July; thanks to Yaron Keren for the catch
llvm-svn: 191756
2013-10-01 13:28:20 +00:00
Marshall Clow 50c003b577 Implement uses-allocator construction
llvm-svn: 190571
2013-09-12 02:11:16 +00:00
Howard Hinnant f0544c2086 Nico Rieck: this patch series fixes visibility issues on Windows as explained in <http://lists.cs.uiuc.edu/pipermail/cfe-dev/2013-August/031214.html>.
llvm-svn: 188192
2013-08-12 18:38:34 +00:00
Marshall Clow 75eff74803 Make tuple's constructor and std::get<>(tuple) constexpr. Final stage of fixing bug #16599. Thanks to Howard for the review and updates.
llvm-svn: 186834
2013-07-22 16:02:19 +00:00
Marshall Clow 8bf1f08a2c Make std::get constexpr
llvm-svn: 186525
2013-07-17 18:25:36 +00:00
Marshall Clow 1c682f0f0c Make std::forward and std::move (and std::move_if_noexcept) constexpr in C++14
llvm-svn: 186344
2013-07-15 20:46:11 +00:00