summaryrefslogtreecommitdiffstats
path: root/libcxx/include/__tuple
Commit message (Collapse)AuthorAgeFilesLines
* Refactor default constructor SFINAE in pair and tuple.Eric Fiselier2019-09-301-2/+3
| | | | | | | Refactor the recent implicit default constructor changes to match the existing SFINAE style. llvm-svn: 373263
* Apply new meta-programming traits throughout the library.Eric Fiselier2019-06-231-1/+1
| | | | | | 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-21/+21
| | | | | | | | | | | | | | | | 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
* [libc++] Declare std::tuple_element as struct instead of classLouis Dionne2019-04-011-11/+6
| | | | | | | | | | | | 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
* Update more file headers across all of the LLVM projects in the monorepoChandler Carruth2019-01-191-4/+3
| | | | | | | | | | | | | | | | | | to reflect the new license. These used slightly different spellings that defeated my regular expressions. 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: 351648
* Change from a to a . Fixes PR#39871.Marshall Clow2019-01-111-9/+9
| | | | llvm-svn: 350972
* Cleanup remaining usages of _LIBCPP_HAS_NO_<c++11-feature> in tuple and utilityEric Fiselier2017-04-191-10/+7
| | | | llvm-svn: 300644
* [NFC] Rename _LIBCPP_TYPE_VIS_ONLY to _LIBCPP_TEMPLATE_VISEric Fiselier2017-01-041-17/+17
| | | | | | | | | | | | | 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
* Fix private inheritance in C++03 tuple_sizeEric Fiselier2017-01-041-3/+3
| | | | llvm-svn: 291032
* [libcxx] Re-implement LWG 2770 again: Fix tuple_size to work with structured ↵Eric Fiselier2017-01-041-17/+22
| | | | | | | | | | | | | | | | | | | bindings 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
* Re-implement LWG 2770 - Fix tuple_size with structured bindings.Eric Fiselier2017-01-021-4/+17
| | | | | | | 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-51/+13
| | | | | | | | 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-13/+51
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Implement LWG 2770 - Make tuple_size<T> defined for all TEric Fiselier2016-11-131-1/+1
| | | | llvm-svn: 286779
* Fix or suppress GCC warnings during build.Eric Fiselier2016-08-291-1/+1
| | | | | | | | | | | | | | | | | | | | Summary: Currently a number of GCC warnings are emitted when building libc++. This patch fixes or ignores all of them. The primary changes are: * Work around strict aliasing issues in `typeinfo::hash_code()` by using __attribute__((may_alias)). However I think a non-aliasing `hash_code()` implementation is possible. Further investigation needed. * Add `_LIBCPP_UNREACHABLE()` to switch in `strstream.cpp` to avoid -Wpotentially-uninitialized. * Fix -Wunused-value warning in `__all` by adding a void cast. * Ignore -Wattributes for now. There are a number of real attribute issues when using GCC but enabling the warning is too noisy. * Ignore -Wliteral-suffix since it warns about the use of reserved identifiers. Note Only GCC 7.0 supports disabling this warning. * Ignore -Wc++14-compat since it warns about the sized new/delete overloads. Reviewers: EricWF Differential Revision: https://reviews.llvm.org/D24003 llvm-svn: 280007
* Check in SFINAE base class for use in optional/variantEric Fiselier2016-08-151-0/+57
| | | | llvm-svn: 278643
* Implement the std::pair parts of "Improving pair and tuple". Completes N4387.Eric Fiselier2016-07-251-0/+46
| | | | llvm-svn: 276605
* Cleanup SFINAE in tuple, and add tests for reference assignmentEric Fiselier2016-07-021-30/+17
| | | | llvm-svn: 274414
* Make tuple_constructible and family lazy again.Eric Fiselier2016-07-021-3/+9
| | | | llvm-svn: 274413
* Flatten tuple_constructible, tuple_convertible and tuple_assignable.Eric Fiselier2016-07-011-77/+40
| | | | | | | | | | | | | | | | 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
* Flatten the tuple_element and __make_tuple_types implementations.Eric Fiselier2016-07-011-33/+105
| | | | | | | | | | 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
* Replace __make_tuple_indices implementation with superior implementation.Eric Fiselier2016-06-301-25/+74
| | | | | | | | | | | | | | | | | The previous __make_tuple_indices implementation caused O(N) instantiations and was pretty inefficient. The C++14 __make_integer_sequence implementation is much better, since it either uses a builtin to generate the sequence or a very nice Log8(N) implementation provided by richard smith. This patch moves the __make_integer_sequence implementation into __tuple and uses it to implement __make_tuple_indices. Since libc++ can't expose the name 'integer_sequence' in C++11 this patch also introduces a dummy type '__integer_sequence' which is used when generating the sequence. One the sequence is generated '__integer_sequence' can be converted into the required type; either '__tuple_indices' or 'integer_sequence'. llvm-svn: 274286
* Extract key to avoid preemptive mallocs in insert/emplace in associative ↵Eric Fiselier2016-04-151-2/+0
| | | | | | | | | | | | | | containers Summary: This patch applies Duncan's work on __hash_table to __tree. Reviewers: mclow.lists, dexonsmith Subscribers: dexonsmith, cfe-commits Differential Revision: http://reviews.llvm.org/D18637 llvm-svn: 266491
* [libcxx] LWG2485: get() should be overloaded for const tuple&&. Patch from ↵Eric Fiselier2015-12-181-0/+15
| | | | | | | K-Ballo. Review: http://reviews.llvm.org/D14839 llvm-svn: 255941
* Move __lazy_* metafunctions to type traits and add testsEric Fiselier2015-08-311-25/+0
| | | | llvm-svn: 246408
* [libcxx] Move tuple_size and tuple_element overloads for pair and array out ↵Eric Fiselier2015-03-171-39/+51
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | of !defined(_LIBCPP_HAS_NO_VARIADICS) block. Summary: There is no reason to guard `tuple_size`, `tuple_element` and `get<I>(...)` for pair and array inside of `<__tuple>` so that they are only available when we have variadic templates. This requires there be redundant declarations and definitions. It also makes it easy to get things wrong. For example the following code should compile (and does in c++11). ``` #define _LIBCPP_HAS_NO_VARIADICS #include <array> int main() { static_assert((std::tuple_size<std::array<int, 10> volatile>::value == 10), ""); } ``` This patch lifts the non-variadic parts of `tuple_size`, `tuple_types`, and `get<I>(...)` to the top of `<__tuple>` where they don't require variadic templates. This patch also removes `<__tuple_03>` because there is no longer a need for it. Reviewers: danalbert, K-ballo, mclow.lists Reviewed By: mclow.lists Subscribers: cfe-commits Differential Revision: http://reviews.llvm.org/D7774 llvm-svn: 232492
* [libcxx] Delay evaluation of __make_tuple_types to prevent blowing the max ↵Eric Fiselier2014-10-281-21/+51
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | template instantiation depth. Fixes Bug #18345 Summary: http://llvm.org/bugs/show_bug.cgi?id=18345 Tuple's constructor and assignment operators for "tuple-like" types evaluates __make_tuple_types unnecessarily. In the case of a large array this can blow the template instantiation depth. Ex: ``` #include <array> #include <tuple> #include <memory> typedef std::array<int, 1256> array_t; typedef std::tuple<array_t> tuple_t; int main() { array_t a; tuple_t t(a); // broken t = a; // broken // make_shared uses tuple behind the scenes. This bug breaks this code. std::make_shared<array_t>(a); } ``` To prevent this from happening we delay the instantiation of `__make_tuple_types` until after we perform the length check. Currently `__make_tuple_types` is instantiated at the same time that the length check . Test Plan: Two tests have been added. One for the "tuple-like" constructors and another for the "tuple-like" assignment operator. Reviewers: mclow.lists, EricWF Reviewed By: EricWF Subscribers: K-ballo, cfe-commits Differential Revision: http://reviews.llvm.org/D4467 llvm-svn: 220769
* D4451: Fix copy/move issues casude by __tuple_leafs's converting constructorEric Fiselier2014-07-241-0/+26
| | | | llvm-svn: 213888
* Nico Rieck: this patch series fixes visibility issues on Windows as ↵Howard Hinnant2013-08-121-15/+15
| | | | | | explained in <http://lists.cs.uiuc.edu/pipermail/cfe-dev/2013-August/031214.html>. llvm-svn: 188192
* Make std::get constexprMarshall Clow2013-07-171-9/+9
| | | | llvm-svn: 186525
* No functionality change at this time. I've split _LIBCPP_VISIBLE up into ↵Howard Hinnant2013-03-061-15/+15
| | | | | | two flags: _LIBCPP_TYPE_VIS and _LIBCPP_FUNC_VIS. This is in preparation for taking advantage of clang's new __type_visibility__ attribute. llvm-svn: 176593
* Dimitry Andric: many visibility fixes. Howard: Much appreciated. Can you ↵Howard Hinnant2012-09-141-0/+9
| | | | | | send me a patch to CREDITS.TXT? llvm-svn: 163862
* I believe tuple is still under development in the standard. Daniel Krugler ↵Howard Hinnant2012-04-011-1/+28
| | | | | | is/will be making convincing arguments that a modified form of LWG 2051 (currently NAD Future) is easily acheivable and desirable. He has demonstrated that a tuple<T...> where all of the T are implicitly convertible from U... should have a tuple constructor that is also implicit, instead of explicit. This would support the use cases in LWG 2051 while not undermining T... with explicit conversions from U.... This check-in is an experimental implementation of Daniel's work. I believe this work to be mature enough to warrant inclusion into libc++. If anyone sees real-world problems that this check in causes, please let me know and I will revert it, and provide the feedback to the LWG. llvm-svn: 153855
* Quash a whole bunch of warningsHoward Hinnant2011-12-011-1/+1
| | | | llvm-svn: 145624
* Windows support by Ruben Van Boxem.Howard Hinnant2011-10-171-0/+2
| | | | llvm-svn: 142235
* Changed constraints on pair and tuple constructors from is_convertible to ↵Howard Hinnant2011-07-011-4/+0
| | | | | | is_constructible. llvm-svn: 134252
* noexcept for <array>.Howard Hinnant2011-05-311-3/+3
| | | | llvm-svn: 132359
* noexcept for <tuple>. And in the process learned that I had done it wrong ↵Howard Hinnant2011-05-271-6/+6
| | | | | | for pair's swap. I needed to create an __is_nothrow_swappable<T>::value trait that was smart enought to answer false when __is_swappable<T>::value is false. Otherwise one gets compile-time errors when using pair or tuple of non-swappable types, even if you never try to swap the pair or tuple. llvm-svn: 132204
* I have to revert this recent fix to tuple conversions until clang implements ↵Howard Hinnant2011-03-101-0/+4
| | | | | | cwg 1170. Without this fix pair and tuple don't convert properly. With it, associative containers get access errors when they shouldn't. cwg 1170 fixes the latter. llvm-svn: 127411
* Chris Jefferson found this bug to pair/tuple introduced by a recent change ↵Howard Hinnant2011-03-011-1/+1
| | | | | | to the draft that I missed. llvm-svn: 126743
* Chandler Carruth changed >> to > > in several places.Howard Hinnant2011-01-241-16/+16
| | | | llvm-svn: 124120
* LWG 1385 [FCD] tuple_cat should be a single variadic signature ↵Howard Hinnant2010-12-111-3/+4
| | | | | | (http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1385). This issue is only in Ready status, meaning it is not official, but probably will be this March in Madrid. It was tentatively accepted in Batavia with the previso that Bill and I didn't have any problems implementing it. This is my part of that agreement. llvm-svn: 121619
* N3123Howard Hinnant2010-11-201-1/+1
| | | | llvm-svn: 119906
* LWG 1191Howard Hinnant2010-11-171-0/+12
| | | | llvm-svn: 119545
* LWG 1118Howard Hinnant2010-11-171-0/+34
| | | | llvm-svn: 119541
* license changeHoward Hinnant2010-11-161-2/+2
| | | | llvm-svn: 119395
* Cleaning up some tuple code.Howard Hinnant2010-09-271-30/+22
| | | | llvm-svn: 114848
* visibility-decoration.Howard Hinnant2010-09-211-9/+9
| | | | llvm-svn: 114470
* Fixing whitespace problemsHoward Hinnant2010-08-221-2/+1
| | | | llvm-svn: 111750
* Wiped out some non-ascii characters that snuck into the copyright.Howard Hinnant2010-05-111-1/+1
| | | | llvm-svn: 103516
OpenPOWER on IntegriCloud