Changes in __tuple

4887d047 - [libc++][NFC] Replace enable_if with __enable_if_t in a few places

Sun, 03 Jul 2022 23:21:44 +0000

[libc++][NFC] Replace enable_if with __enable_if_t in a few placesReviewed By: ldionne, #libcSpies: jloser, libcxx-commitsDifferential Revision: https://reviews.llvm.org/D128400 List of files: /llvm-project-15.0.7/libcxx/include/__tuple

368faaca - [libc++] Revert "Protect users from relying on detail headers" & related changes

Mon, 28 Feb 2022 21:37:25 +0000

[libc++] Revert "Protect users from relying on detail headers" & related changesThis commit reverts 5aaefa51 (and also partly 7f285f48e77 and b6d75682f9,which were related to the original commit). As landed, 5aaefa51 hadunintended consequences on some downstream bots and didn't have propercoverage upstream due to a few subtle things. Implementing this issomething we should do in libc++, however we'll first need to addressa few issues listed in https://reviews.llvm.org/D106124#3349710.Differential Revision: https://reviews.llvm.org/D120683 List of files: /llvm-project-15.0.7/libcxx/include/__tuple

5aaefa51 - [libcxx][modules] protects users from relying on detail headers

Fri, 25 Feb 2022 18:59:32 +0000

[libcxx][modules] protects users from relying on detail headerslibc++ has started splicing standard library headers into much morefine-grained content for maintainability. It's very likely that outdatedand naive tooling (some of which is outside of LLVM's scope) willsuggest users include things such as <__ranges/access.h> instead of, and Hyrum's law suggests that users will eventually begin torely on this without the help of tooling. As such, this commitintends to protect users from themselves, by making it a hard error foranyone outside of the standard library to include libc++ detail headers.Differential Revision: https://reviews.llvm.org/D106124 List of files: /llvm-project-15.0.7/libcxx/include/__tuple

f7558068 - Remove uncvref; use uncvref_t instead

Thu, 17 Feb 2022 21:53:20 +0000

Remove __uncvref; use __uncvref_t insteadReviewed By: Quuxplusone, #libcSpies: libcxx-commitsDifferential Revision: https://reviews.llvm.org/D119958 List of files: /llvm-project-15.0.7/libcxx/include/__tuple

fa6b9e40 - [libc++] Normalize all our '#pragma GCC system_header', and regression-test.

Wed, 02 Feb 2022 01:16:40 +0000

[libc++] Normalize all our '#pragma GCC system_header', and regression-test.Now we'll notice if a header forgets to include this magic phrase.Differential Revision: https://reviews.llvm.org/D118800 List of files: /llvm-project-15.0.7/libcxx/include/__tuple

5c0ea748 - [libc++] Enable the optimized _IsSame on GCC as well as Clang.

Fri, 03 Dec 2021 19:55:57 +0000

[libc++] Enable the optimized _IsSame on GCC as well as Clang.However, there's a problem on both GCC and Clang: they can't mangle`__is_same(T,U)` if it appears anywhere that affects mangling. That'sa hard error. And it turns out that GCC puts dependent return typesinto the mangling more aggressively than Clang, so for GCC's benefitwe need to avoid using raw `_IsSame` in the return type of`swap(tuple&, tuple&)`. Therefore, make `__all` into a named typeinstead of an alias.If we ever need to support a compiler without the __is_same builtin,we can make this an alias template for `is_same::type`.Differential Revision: https://reviews.llvm.org/D115100 List of files: /llvm-project-15.0.7/libcxx/include/__tuple

3557c7c1 - [libc++] Remove workarounds for [[nodebug]] not working properly on typedefs in older Clangs

Tue, 31 Aug 2021 14:32:11 +0000

[libc++] Remove workarounds for [[nodebug]] not working properly on typedefs in older ClangsClang used to support [[nodebug]] everywhere except on typedefs. Sincewe don't support such old Clangs anymore, we can get rid of _LIBCPP_NODEBUG_TYPEin favour of always using _LIBCPP_NODEBUG.Differential Revision: https://reviews.llvm.org/D108996 List of files: /llvm-project-15.0.7/libcxx/include/__tuple

4cd6ca10 - [libc++] NFC: Normalize `#endif //` comment indentation

Tue, 20 Apr 2021 16:03:32 +0000

[libc++] NFC: Normalize `#endif //` comment indentation List of files: /llvm-project-15.0.7/libcxx/include/__tuple

c8ad8686 - Refactor default constructor SFINAE in pair and tuple.

Mon, 30 Sep 2019 20:55:30 +0000

Refactor default constructor SFINAE in pair and tuple.Refactor the recent implicit default constructor changes to match theexisting SFINAE style.llvm-svn: 373263 List of files: /llvm-project-15.0.7/libcxx/include/__tuple

3359a17b - Apply new meta-programming traits throughout the library.

Sun, 23 Jun 2019 20:28:29 +0000

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 List of files: /llvm-project-15.0.7/libcxx/include/__tuple

14d48692 - Apply [[nodebug]] to typedefs throughout the STL.

Wed, 12 Jun 2019 02:03:31 +0000

Apply [[nodebug]] to typedefs throughout the STL.When applied to a typedef or alias template, the [[nodebug]] attributemakes the typedef transparent to the debugger, so instead of seeing`std::__function::__alloc_func::type,allocator, 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 sizewins, in addition to improving the readability.For now this change is on by default. Users can override it byspecifying -D_LIBCPP_NODEBUG_TYPE=llvm-svn: 363117 List of files: /llvm-project-15.0.7/libcxx/include/__tuple

2b0c7abb - [libc++] Declare std::tuple_element as struct instead of class

Mon, 01 Apr 2019 16:39:34 +0000

[libc++] Declare std::tuple_element as struct instead of classSimilarly to https://reviews.llvm.org/rL350972, this revision changesstd::tuple_element from class to struct.Fixes PR41331.Thanks to Jan Wilken Dörrie for the patch.Differential Revision: https://reviews.llvm.org/D60069llvm-svn: 357411 List of files: /llvm-project-15.0.7/libcxx/include/__tuple

57b08b09 - Update more file headers across all of the LLVM projects in the monorepo

Sat, 19 Jan 2019 10:56:40 +0000

Update more file headers across all of the LLVM projects in the monorepoto reflect the new license. These used slightly different spellings thatdefeated my regular expressions.We understand that people may be surprised that we're moving the headerentirely to discuss the new license. We checked this carefully with theFoundation's lawyer and we believe this is the correct approach.Essentially, all code in the project is now made available by the LLVMproject under our new license, so you will see that the license headersinclude that license only. Some of our contributors have contributedcode under our old license, and accordingly, we have retained a copy ofour old license notice in the top-level files in each project andrepository.llvm-svn: 351648 List of files: /llvm-project-15.0.7/libcxx/include/__tuple

e4957601 - Change from a to a . Fixes PR#39871.

Fri, 11 Jan 2019 21:57:12 +0000

Change from a to a . Fixes PR#39871.llvm-svn: 350972 List of files: /llvm-project-15.0.7/libcxx/include/__tuple

29870871 - Cleanup remaining usages of _LIBCPP_HAS_NO_ in tuple and utility

Wed, 19 Apr 2017 01:23:39 +0000

Cleanup remaining usages of _LIBCPP_HAS_NO_ in tuple and utilityllvm-svn: 300644 List of files: /llvm-project-15.0.7/libcxx/include/__tuple

e2f2d1ed - [NFC] Rename _LIBCPP_TYPE_VIS_ONLY to _LIBCPP_TEMPLATE_VIS

Wed, 04 Jan 2017 23:56:00 +0000

[NFC] Rename _LIBCPP_TYPE_VIS_ONLY to _LIBCPP_TEMPLATE_VISThe 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 differenceis that _LIBCPP_TYPE_VIS_ONLY can be applied to templates whereas_LIBCPP_TYPE_VIS cannot (due to dllimport/dllexport not being allowed ontemplates).This patch renames _LIBCPP_TYPE_VIS_ONLY to _LIBCPP_TEMPLATE_VIS.llvm-svn: 291035 List of files: /llvm-project-15.0.7/libcxx/include/__tuple

e5b41f7c - Fix private inheritance in C++03 tuple_size

Wed, 04 Jan 2017 23:35:51 +0000

Fix private inheritance in C++03 tuple_sizellvm-svn: 291032 List of files: /llvm-project-15.0.7/libcxx/include/__tuple

cb0d4df9 - [libcxx] Re-implement LWG 2770 again: Fix tuple_size to work with structured bindings

Wed, 04 Jan 2017 22:38:46 +0000

[libcxx] Re-implement LWG 2770 again: Fix tuple_size to work with structured bindingsSummary:This patch attempts to re-implement a fix for LWG 2770, but not the actual specified PR. The PR for 2770 specifies tuple_size as only conditionally providing a `::value` member. However C++17 structured bindings require `tuple_size` to be complete only if `tuple_size` is also complete. Therefore this patch implements only provides the specialization `tuple_size` iff `tuple_size` is a complete type.This fixes http://llvm.org/PR31513.Reviewers: mclow.lists, rsmith, mparkSubscribers: mpark, cfe-commitsDifferential Revision: https://reviews.llvm.org/D28222llvm-svn: 291019 List of files: /llvm-project-15.0.7/libcxx/include/__tuple

1013fe3c - Re-implement LWG 2770 - Fix tuple_size with structured bindings.

Mon, 02 Jan 2017 23:54:13 +0000

Re-implement LWG 2770 - Fix tuple_size with structured bindings.This patch implements the correct PR for LWG 2770. It also makes the primarytuple_size template incomplete again which fixes part of llvm.org/PR31513.llvm-svn: 290846 List of files: /llvm-project-15.0.7/libcxx/include/__tuple

347a1cc2 - Revert r289727 due to PR31384

Thu, 15 Dec 2016 06:34:54 +0000

Revert r289727 due to PR31384This patch reverts the changes to tuple which fixed construction fromtypes 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 List of files: /llvm-project-15.0.7/libcxx/include/__tuple