summaryrefslogtreecommitdiffstats
path: root/libcxx/include/tuple
Commit message (Collapse)AuthorAgeFilesLines
* PR43764: Qualify a couple of calls to forward_as_tuple to be ADL-resilient.David Blaikie2019-10-281-11/+13
|
* Refactor default constructor SFINAE in pair and tuple.Eric Fiselier2019-09-301-28/+17
| | | | | | | Refactor the recent implicit default constructor changes to match the existing SFINAE style. llvm-svn: 373263
* [libc++] Take 2: Implement LWG 3158Louis Dionne2019-09-271-13/+29
| | | | | | | | | | | | | | | | | | | | | Summary: LWG 3158 marks the allocator_arg_t constructor of std::tuple as conditionnally explicit based on whether the default constructors of the tuple's members are explicitly default constructible. This was previously committed as r372778 and reverted in r372832 due to the commit breaking LLVM's build in C++14 mode. This issue has now been addressed. Reviewers: mclow.lists Subscribers: christof, jkorous, dexonsmith, libcxx-commits Tags: #libc Differential Revision: https://reviews.llvm.org/D65232 llvm-svn: 373092
* [libc++] Take 2: Implement LWG 2510Louis Dionne2019-09-261-8/+26
| | | | | | | | | | | | | | | | | | | | | | | Summary: LWG2510 makes tag types like allocator_arg_t explicitly default constructible instead of implicitly default constructible. It also makes the constructors for std::pair and std::tuple conditionally explicit based on the explicit-ness of the default constructibility for the pair/tuple's elements. This was previously committed as r372777 and reverted in r372832 due to the commit breaking LLVM's build in C++14 mode. This issue has now been addressed. Reviewers: mclow.lists Subscribers: christof, jkorous, dexonsmith, libcxx-commits Tags: #libc Differential Revision: https://reviews.llvm.org/D65161 llvm-svn: 372983
* Revert r372777: [libc++] Implement LWG 2510 and its follow-upsIlya Biryukov2019-09-251-46/+12
| | | | | | | | | | | | This also reverts: - r372778: [libc++] Implement LWG 3158 - r372782: [libc++] Try fixing tests that fail on GCC 5 and older - r372787: Purge mentions of GCC 4 from the test suite Reason: the change breaks compilation of LLVM with libc++, for details see http://lists.llvm.org/pipermail/libcxx-dev/2019-September/000599.html llvm-svn: 372832
* [libc++] Implement LWG 3158Louis Dionne2019-09-241-13/+29
| | | | | | | | | | | | | | | | | Summary: LWG 3158 marks the allocator_arg_t constructor of std::tuple as conditionnally explicit based on whether the default constructors of the tuple's members are explicitly default constructible. Reviewers: EricWF, mclow.lists Subscribers: christof, jkorous, dexonsmith, libcxx-commits Tags: #libc Differential Revision: https://reviews.llvm.org/D65232 llvm-svn: 372778
* [libc++] Implement LWG 2510Louis Dionne2019-09-241-8/+26
| | | | | | | | | | | | | | | | | | | Summary: LWG2510 makes tag types like allocator_arg_t explicitly default constructible instead of implicitly default constructible. It also makes the constructors for std::pair and std::tuple conditionally explicit based on the explicit-ness of the default constructibility for the pair/tuple's elements. Reviewers: mclow.lists, EricWF Subscribers: christof, jkorous, dexonsmith, libcxx-commits Tags: #libc Differential Revision: https://reviews.llvm.org/D65161 llvm-svn: 372777
* [libc++] Implement CTAD for std::tupleLouis Dionne2019-08-121-7/+21
| | | | | | | | | | | | | | | | | | | | | Summary: We were using implicit deduction guides instead of explicit ones, however the implicit ones don't do work anymore when changing the constructors. This commit adds the actual guides specified in the Standard to make libc++ (1) closer to the Standard and (2) more resistent to changes in std::tuple's constructors. Reviewers: Quuxplusone Subscribers: christof, jkorous, dexonsmith, libcxx-commits Tags: #libc Differential Revision: https://reviews.llvm.org/D65225 llvm-svn: 368599
* [NFC][libc++] Add missing EXPLICIT to pair and tuple synopsisLouis Dionne2019-07-221-12/+12
| | | | | | | The constructors for std::pair and std::tuple have been made conditionally explicit, however the synopsis in the headers do not reflect that. llvm-svn: 366735
* Fix non-conformance it `std::tuple`.Eric Fiselier2019-07-121-20/+31
| | | | | | | | | | | | | | Previously we implemented all one trillion tuple-like constructors using a single generic overload. This worked fairly well, except that it differed in behavior from the standard version because it didn't consider both T&& and T const&. This was observable for certain types. This patch addresses that issue by splitting the generic constructor in two. We now provide both T&& and T const& versions of the tuple-like constructors (sort of). llvm-svn: 365973
* Fix tuple's conditionally explicit constructors for very weird userEric Fiselier2019-07-031-1/+10
| | | | | | | | | | | | types. It seems some people like to write types that can explicitly convert to anything, but cannot be used to explicitly construct anything. This patch makes tuple tolerate such types, as is required by the standard. llvm-svn: 365074
* Apply new meta-programming traits throughout the library.Eric Fiselier2019-06-231-27/+25
| | | | | | The new meta-programming primitives are lower cost than the old versions. This patch removes those old versions and switches libc++ to use the new ones. llvm-svn: 364160
* Apply [[nodebug]] to typedefs throughout the STL.Eric Fiselier2019-06-121-11/+11
| | | | | | | | | | | | | | | | When applied to a typedef or alias template, the [[nodebug]] attribute makes the typedef transparent to the debugger, so instead of seeing `std::__function::__alloc_func<remove_reference<void(&)()>::type, allocator<remove_reference<void(&)()>, void()>::_Target` you see `void(&)()` as the type of the variable in your debugger. Removing all this SFINAE noise from debug info has huge binary size wins, in addition to improving the readability. For now this change is on by default. Users can override it by specifying -D_LIBCPP_NODEBUG_TYPE= llvm-svn: 363117
* [libcxx] Make std::tuple<> trivially constructibleLouis Dionne2019-06-111-1/+1
| | | | | | | | | | | | | | | | | | | Summary: This is not mandated by the Standard, but it's nonetheless a nice property to have, especially since it's so easy to implement. It also shrinks our bug list! PR41714 Reviewers: mclow.lists, EricWF Subscribers: christof, jkorous, dexonsmith, libcxx-commits Tags: #libc Differential Revision: https://reviews.llvm.org/D62618 llvm-svn: 363075
* Fix return type of std::tuple_cat.Eric Fiselier2019-04-261-2/+2
| | | | | | | | | | | | When the arguments to tuple cat were const, the const was incorrectly propagated into the type of the resulting tuple. For example: const std::tuple<int> t(42); auto r = std::tuple_cat(t, t); // Incorrect! should be std::tuple<int, int>. static_assert(is_same_v<decltype(r), std::tuple<const int, const int>>); llvm-svn: 359255
* [libc++] Declare std::tuple_element as struct instead of classLouis Dionne2019-04-011-2/+2
| | | | | | | | | | | | Similarly to https://reviews.llvm.org/rL350972, this revision changes std::tuple_element from class to struct. Fixes PR41331. Thanks to Jan Wilken Dörrie for the patch. Differential Revision: https://reviews.llvm.org/D60069 llvm-svn: 357411
* Add static_asserts to tuple's comparison operators to enforce the ↵Marshall Clow2019-02-071-0/+2
| | | | | | requirement that the tuples be the same size. See PR39183 for an example where we give unexpected results for this bad input case. With this change, we will reject it at compile-time llvm-svn: 353450
* Update the file headers across all of the LLVM projects in the monorepoChandler Carruth2019-01-191-4/+3
| | | | | | | | | | | | | | | | | to reflect the new license. We understand that people may be surprised that we're moving the header entirely to discuss the new license. We checked this carefully with the Foundation's lawyer and we believe this is the correct approach. Essentially, all code in the project is now made available by the LLVM project under our new license, so you will see that the license headers include that license only. Some of our contributors have contributed code under our old license, and accordingly, we have retained a copy of our old license notice in the top-level files in each project and repository. llvm-svn: 351636
* Change from a to a . Fixes PR#39871.Marshall Clow2019-01-111-2/+2
| | | | llvm-svn: 350972
* [libcxx] Implement P0318: unwrap_ref_decay and unwrap_referenceLouis Dionne2018-12-031-20/+2
| | | | | | | | | | | | | | | | | | 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 llvm-svn: 348138
* [NFC] Fix typo in <tuple>Louis Dionne2018-11-121-1/+1
| | | | llvm-svn: 346629
* Implement the infrastructure for feature-test macros. Very few actual ↵Marshall Clow2018-09-121-0/+1
| | | | | | feature test macros, though. Reviewed as: https://reviews.llvm.org/D51955 llvm-svn: 342073
* Implement P0777: Treating unnecessay decayMarshall Clow2018-02-061-4/+4
| | | | llvm-svn: 324398
* Fix missing return in __tuple_leaf::__can_bind_reference when ↵Eric Fiselier2018-01-241-0/+2
| | | | | | __reference_binds_to_temporary added in r323380. llvm-svn: 323389
* [libc++] Fix PR20855 -- libc++ incorrectly diagnoses illegal reference ↵Eric Fiselier2018-01-241-14/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | binding in std::tuple. 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
* Implement most of P0607: Inline Variables for the Standard Library. This ↵Marshall Clow2018-01-021-4/+4
| | | | | | involved marking a lot of variables as inline (but only for C++17 and later). llvm-svn: 321658
* workaround PR 28385 in __find_exactly_one_checkedCasey Carter2017-12-121-3/+3
| | | | | | | | Fixes #35578. Differential Revision: D41048 llvm-svn: 320500
* Add C++17 explicit deduction guides to std::pair.Eric Fiselier2017-10-041-1/+1
| | | | | | | This patch adds the newly standardized deduction guides for std::pair, allowing it to work class template deduction. llvm-svn: 314864
* Add tests for class template deduction on std::tuple.Eric Fiselier2017-06-081-0/+10
| | | | llvm-svn: 304967
* Rename unreserved names in tupleEric Fiselier2017-06-011-40/+40
| | | | llvm-svn: 304382
* Cleanup remaining usages of _LIBCPP_HAS_NO_<c++11-feature> in tuple and utilityEric Fiselier2017-04-191-5/+3
| | | | llvm-svn: 300644
* Implement LWG 2773 - std::ignore should be constexpr.Eric Fiselier2017-02-061-3/+5
| | | | | | | | 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
* Fix inconsistency in tuple's SFINAE. Patch from Andrey Khalyavin"Eric Fiselier2017-02-041-1/+1
| | | | llvm-svn: 294106
* Fix std::tuples EBO when targeting the MSVC ABI.Eric Fiselier2017-01-161-1/+1
| | | | | | | | | | | 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
* [NFC] Rename _LIBCPP_TYPE_VIS_ONLY to _LIBCPP_TEMPLATE_VISEric Fiselier2017-01-041-3/+3
| | | | | | | | | | | | | 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
* Re-implement LWG 2770 - Fix tuple_size with structured bindings.Eric Fiselier2017-01-021-1/+1
| | | | | | | 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
* Revert r289727 due to PR31384Eric Fiselier2016-12-151-40/+23
| | | | | | | | 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
* [libcxx] Fix tuple construction/assignment from types derived from ↵Eric Fiselier2016-12-141-23/+40
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Fix PR27374 - Remove the implicit reduced-arity-extension in tuple.Eric Fiselier2016-12-081-3/+20
| | | | | | | | | | | | | | | | | | | 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
* Implement LWG 2770 - Make tuple_size<T> defined for all TEric Fiselier2016-11-131-1/+1
| | | | llvm-svn: 286779
* Fix PR30979 - tuple<move_only> is constructible from move_only const&Eric Fiselier2016-11-131-4/+4
| | | | llvm-svn: 286774
* Implement the std::pair parts of "Improving pair and tuple". Completes N4387.Eric Fiselier2016-07-251-44/+10
| | | | llvm-svn: 276605
* Recommit r276548 - Make pair/tuples assignment operators SFINAE properly.Eric Fiselier2016-07-251-0/+22
| | | | | | | 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
* Revert r276548 - Make pair/tuples assignment operators SFINAE properly.Eric Fiselier2016-07-251-22/+0
| | | | | | | | | | | | 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
* Make pair/tuples assignment operators SFINAE properly.Eric Fiselier2016-07-241-0/+22
| | | | llvm-svn: 276548
* Add tests for reference binding assertions in std::tuple.Eric Fiselier2016-07-201-36/+20
| | | | | | | | | | | | 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
* Implement C++17 tuple bits. Including apply and make_from_tuple.Eric Fiselier2016-07-181-1/+53
| | | | | | | | | | 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
* Handle std::get<T>(...) for std::tuple<>Eric Fiselier2016-07-021-0/+5
| | | | llvm-svn: 274422
* Rewrite std::get<Type>(...) helper using constexpr functions.Eric Fiselier2016-07-021-28/+28
| | | | llvm-svn: 274418
* Flatten tuple_constructible, tuple_convertible and tuple_assignable.Eric Fiselier2016-07-011-5/+0
| | | | | | | | | | | | | | | | 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
OpenPOWER on IntegriCloud