Commit Graph

52 Commits

Author SHA1 Message Date
Louis Dionne 4cd6ca102a [libc++] NFC: Normalize `#endif //` comment indentation 2021-04-20 12:03:32 -04:00
Eric Fiselier c8ad8686ac Refactor default constructor SFINAE in pair and tuple.
Refactor the  recent implicit default constructor changes to match the
existing SFINAE style.

llvm-svn: 373263
2019-09-30 20:55:30 +00:00
Eric Fiselier 3359a17b3a Apply new meta-programming traits throughout the library.
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
2019-06-23 20:28:29 +00:00
Eric Fiselier 14d4869209 Apply [[nodebug]] to typedefs throughout the STL.
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
2019-06-12 02:03:31 +00:00
Louis Dionne 2b0c7abba3 [libc++] Declare std::tuple_element as struct instead of class
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
2019-04-01 16:39:34 +00:00
Chandler Carruth 57b08b0944 Update more file headers across all of the LLVM projects in the monorepo
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
2019-01-19 10:56:40 +00:00
Marshall Clow e495760140 Change from a to a . Fixes PR#39871.
llvm-svn: 350972
2019-01-11 21:57:12 +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 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 e5b41f7ccf Fix private inheritance in C++03 tuple_size
llvm-svn: 291032
2017-01-04 23:35:51 +00:00
Eric Fiselier cb0d4df974 [libcxx] Re-implement LWG 2770 again: Fix tuple_size to work with structured 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
2017-01-04 22:38:46 +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 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 f6ac565031 Fix or suppress GCC warnings during build.
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
2016-08-29 20:43:38 +00:00
Eric Fiselier 921a3f1c8d Check in SFINAE base class for use in optional/variant
llvm-svn: 278643
2016-08-15 01:51:54 +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 27cdf401ea Cleanup SFINAE in tuple, and add tests for reference assignment
llvm-svn: 274414
2016-07-02 01:25:46 +00:00
Eric Fiselier 7b60958aea Make tuple_constructible and family lazy again.
llvm-svn: 274413
2016-07-02 00:58:17 +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 10b9a1bb42 Flatten the tuple_element and __make_tuple_types implementations.
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
2016-07-01 03:54:54 +00:00
Eric Fiselier 9743af6e31 Replace __make_tuple_indices implementation with superior implementation.
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
2016-06-30 22:34:43 +00:00
Eric Fiselier fa1f613f7e Extract key to avoid preemptive mallocs in insert/emplace in associative 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
2016-04-15 23:27:27 +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
Eric Fiselier 888d91a9e4 Move __lazy_* metafunctions to type traits and add tests
llvm-svn: 246408
2015-08-31 03:50:31 +00:00
Eric Fiselier 57f00f2f9c [libcxx] Move tuple_size and tuple_element overloads for pair and array out 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
2015-03-17 15:08:03 +00:00
Eric Fiselier 295bce1130 [libcxx] Delay evaluation of __make_tuple_types to prevent blowing the max 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
2014-10-28 06:31:22 +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
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 8bf1f08a2c Make std::get constexpr
llvm-svn: 186525
2013-07-17 18:25:36 +00:00
Howard Hinnant 6e41256f68 No functionality change at this time. I've split _LIBCPP_VISIBLE up into 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
2013-03-06 23:30:19 +00:00
Howard Hinnant aeb85680fb Dimitry Andric: many visibility fixes. Howard: Much appreciated. Can you send me a patch to CREDITS.TXT?
llvm-svn: 163862
2012-09-14 00:39:16 +00:00
Howard Hinnant 0527c6207a I believe tuple is still under development in the standard. Daniel Krugler 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
2012-04-01 23:10:42 +00:00
Howard Hinnant c206366fd7 Quash a whole bunch of warnings
llvm-svn: 145624
2011-12-01 20:21:04 +00:00
Howard Hinnant 073458b1ab Windows support by Ruben Van Boxem.
llvm-svn: 142235
2011-10-17 20:05:10 +00:00
Howard Hinnant b929de3c3d Changed constraints on pair and tuple constructors from is_convertible to is_constructible.
llvm-svn: 134252
2011-07-01 20:12:51 +00:00
Howard Hinnant 8f0cd597f1 noexcept for <array>.
llvm-svn: 132359
2011-05-31 21:06:33 +00:00
Howard Hinnant 27d0a2a75d noexcept for <tuple>. And in the process learned that I had done it wrong 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
2011-05-27 19:08:18 +00:00
Howard Hinnant 8cad46266c I have to revert this recent fix to tuple conversions until clang implements 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
2011-03-10 17:27:30 +00:00
Howard Hinnant b5d166ad93 Chris Jefferson found this bug to pair/tuple introduced by a recent change to the draft that I missed.
llvm-svn: 126743
2011-03-01 14:27:55 +00:00
Howard Hinnant 465abe92a5 Chandler Carruth changed >> to > > in several places.
llvm-svn: 124120
2011-01-24 16:07:25 +00:00
Howard Hinnant 7f64810bc8 LWG 1385 [FCD] tuple_cat should be a single variadic signature (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
2010-12-11 20:47:50 +00:00
Howard Hinnant 092980dd65 N3123
llvm-svn: 119906
2010-11-20 18:25:22 +00:00
Howard Hinnant 601afb30ec LWG 1191
llvm-svn: 119545
2010-11-17 19:52:17 +00:00
Howard Hinnant ef6168357a LWG 1118
llvm-svn: 119541
2010-11-17 19:22:43 +00:00
Howard Hinnant 412dbebe1b license change
llvm-svn: 119395
2010-11-16 22:09:02 +00:00
Howard Hinnant 30ad985b6b Cleaning up some tuple code.
llvm-svn: 114848
2010-09-27 17:54:17 +00:00
Howard Hinnant f5ab703f68 visibility-decoration.
llvm-svn: 114470
2010-09-21 20:16:37 +00:00
Howard Hinnant b3371f6f49 Fixing whitespace problems
llvm-svn: 111750
2010-08-22 00:02:43 +00:00