aboutsummaryrefslogtreecommitdiff
path: root/libcxx/include/tuple
AgeCommit message (Collapse)AuthorFilesLines
2023-12-18[libc++] Format the code base (#74334)Louis Dionne1-1178/+948
This patch runs clang-format on all of libcxx/include and libcxx/src, in accordance with the RFC discussed at [1]. Follow-up patches will format the benchmarks, the test suite and remaining parts of the code. I'm splitting this one into its own patch so the diff is a bit easier to review. This patch was generated with: find libcxx/include libcxx/src -type f \ | grep -v 'module.modulemap.in' \ | grep -v 'CMakeLists.txt' \ | grep -v 'README.txt' \ | grep -v 'libcxx.imp' \ | grep -v '__config_site.in' \ | xargs clang-format -i A Git merge driver is available in libcxx/utils/clang-format-merge-driver.sh to help resolve merge and rebase issues across these formatting changes. [1]: https://discourse.llvm.org/t/rfc-clang-formatting-all-of-libc-once-and-for-all
2023-12-05[libc++] Replace uses of _VSTD:: by std:: (#74331)Louis Dionne1-69/+69
As part of the upcoming clang-formatting of libc++, this patch performs the long desired removal of the _VSTD macro. See https://discourse.llvm.org/t/rfc-clang-formatting-all-of-libc-once-and-for-all for the clang-format proposal.
2023-12-04[libc++][NFC] Add a few clang-format annotations (#74352)Louis Dionne1-0/+4
This is in preparation for clang-formatting the whole code base. These annotations are required either to avoid clang-format bugs or because the manually formatted code is significantly more readable than the clang-formatted alternative. All in all, it seems like very few annotations are required, which means that clang-format is doing a very good job in most cases.
2023-12-04[libc++] Rename _LIBCPP_INLINE_VISIBILITY to _LIBCPP_HIDE_FROM_ABI (#74095)Louis Dionne1-99/+99
In preparation for running clang-format on the whole code base, we are also removing mentions of the legacy _LIBCPP_INLINE_VISIBILITY macro in favor of the newer _LIBCPP_HIDE_FROM_ABI. We're still leaving the definition of _LIBCPP_INLINE_VISIBILITY to avoid creating needless breakage in case some older patches are checked-in with mentions of the old macro. After we branch for LLVM 18, we can do another pass to clean up remaining uses of the macro that might have gotten introduced by mistake (if any) and remove the macro itself at the same time. This is just a minor convenience to smooth out the transition as much as possible. See https://discourse.llvm.org/t/rfc-clang-formatting-all-of-libc-once-and-for-all for the clang-format proposal.
2023-10-16[libc++] Simplify the tuple constructor overload setNikolas Klauser1-223/+34
This uses conditional explicit to avoid having two overloads for implicit/explicit conversions. Reviewed By: ldionne, #libc Spies: jrtc27, dblaikie, #clang-vendors, #libc_vendors, aaron.ballman, libcxx-commits Differential Revision: https://reviews.llvm.org/D148432
2023-09-26[libc++] Use _Lazy in tuple constructorsLouis Dionne1-4/+4
This reduces the number of instantiations and also avoid blowing up past the fold-expression limit of Clang. This is NOT a general statement that we should strive to stay within Clang's (sometimes way too small) limits, however in this case the change will reduce the number of template instantiations while at the same time doing that, which is good. Differential Revision: https://reviews.llvm.org/D132509
2023-09-07Revert "[libc++][NFC] Remove __has_keyword"Xing Xue1-1/+1
This reverts commit cd34e89cfabbc43a89bac5f0e4e84ebee0e4e167. See https://reviews.llvm.org/D158215#inline-1544266 for details.
2023-09-01[libc++][NFC] Refactor __enable_if return types to defaulted template parametersNikolas Klauser1-2/+2
This brings most of the enable_ifs in libc++ to the same style. It also has the nice side-effect of reducing the size of names of these symbols, since the depedent return type is shorter. Reviewed By: #libc, ldionne Spies: ldionne, libcxx-commits Differential Revision: https://reviews.llvm.org/D157787
2023-08-19[libc++][NFC] Remove __has_keywordNikolas Klauser1-1/+1
__has_keyword is almost not used anymore. There are only two cases. One can be replaced by __has_builtin and the other seems entirely redundant, so we can remove the definition. Reviewed By: #libc, Mordante Spies: Mordante, libcxx-commits Differential Revision: https://reviews.llvm.org/D158215
2023-07-24[libc++] Fix template parameter naming and enforce it through ↵Nikolas Klauser1-10/+10
readability-identifier-naming Reviewed By: #libc, Mordante Spies: Mordante, aheejin, libcxx-commits Differential Revision: https://reviews.llvm.org/D156059
2023-07-07[libc++][Modules] Add missing __fwd includesIan Anderson1-0/+1
A few __fwd includes are missing from public modules that will become noticeable when the private submodules are split into their own top level modules (D144322). Add the missing includes. Reviewed By: ldionne, philnik, #libc Differential Revision: https://reviews.llvm.org/D153216
2023-07-06Fixing conflicting macro definitions between curses.h and the standard library.Nicole Rabjohn1-0/+5
POSIX allows certain macros to exist with generic names (i.e. refresh(), move(), and erase()) to exist in `curses.h` which conflict with functions found in std::filesystem, among others. This patch undefs the macros in question and adds them to LIBCPP_PUSH_MACROS and LIBCPP_POP_MACROS. Reviewed By: #libc, philnik, ldionne Differential Revision: https://reviews.llvm.org/D147356
2023-05-31[libc++] Gives ignore external linkage.Mark de Wever1-0/+4
A slightly different fix is in D144994. Reviewed By: #libc, ldionne Differential Revision: https://reviews.llvm.org/D151490
2023-05-14[libc++] Moves unwrap_reference to type_traits.Mark de Wever1-1/+1
This was discovered while working on modules. Reviewed By: #libc, philnik Differential Revision: https://reviews.llvm.org/D149351
2023-05-07[libc++][Modules] Add missing includes and exportsIan Anderson1-0/+8
Several headers are missing includes for things they use. type_traits.is_enum needs to export type_traits.integral_constant so that clients can access its `value` member without explicitly including __type_traits/integral_constant.h themselves. Make `subrange_fwd` a peer submodule to `subrange` rather than a submodule of it, and have `subrange` export `subrange_fwd`. That will make it easier to programmatically generate modules for the private detail headers, and it will accomplish the same effect that __ranges/subrange.h will make subrange_kind visible. Reviewed By: Mordante, #libc Differential Revision: https://reviews.llvm.org/D150055
2023-04-20[libc++][NFC] Remove one apply_cv implementationNikolas Klauser1-12/+6
Reviewed By: #libc, ldionne Spies: arichardson, libcxx-commits Differential Revision: https://reviews.llvm.org/D148468
2023-04-16[libc++] Add hide_from_abi check for classesNikolas Klauser1-5/+4
We already have a clang-tidy check for making sure that `_LIBCPP_HIDE_FROM_ABI` is on free functions. This patch extends this to class members. The places where we don't check for `_LIBCPP_HIDE_FROM_ABI` are classes for which we have an instantiation in the library. Reviewed By: ldionne, Mordante, #libc Spies: jplehr, mikhail.ramalho, sstefan1, libcxx-commits, krytarowski, miyuki, smeenai Differential Revision: https://reviews.llvm.org/D142332
2023-02-15[libc++][NFC] Replace _LIBCPP_STD_VER > x with _LIBCPP_STD_VER >= xNikolas Klauser1-26/+26
This change is almost fully mechanical. The only interesting change is in `generate_feature_test_macro_components.py` to generate `_LIBCPP_STD_VER >=` instead. To avoid churn in the git-blame this commit should be added to the `.git-blame-ignore-revs` once committed. Reviewed By: ldionne, var-const, #libc Spies: jloser, libcxx-commits, arichardson, arphaman, wenlei Differential Revision: https://reviews.llvm.org/D143962
2023-01-15[libc++][ranges] implement `std::views::elements_view`Hui Xie1-2/+2
`subrange` is also a `tuple-like`. To avoid the add entire `subrange` dependencies to `tuple-like`, we need forward declaration of `subrange`. However, the class template constraints of `subrange` currently requires `__iterator/concepts.h`, which requires `<concepts>`. The problem is that currently `tuple-like` is used in several different places, including libc++ extension for pair constructors. we don't want to add `<concepts>` to pair and other stuff. So this change also created several small headers that `subrange`'s declaration needed inside `__iterator/concepts/` Differential Revision: https://reviews.llvm.org/D136268
2022-12-27[libc++] Granularize <type_traits> includes in <iterator>Nikolas Klauser1-1/+35
Reviewed By: Mordante, #libc Spies: libcxx-commits Differential Revision: https://reviews.llvm.org/D140621
2022-12-23[libc++] Add custom clang-tidy checksNikolas Klauser1-1/+1
Reviewed By: #libc, ldionne Spies: jwakely, beanz, smeenai, cfe-commits, tschuett, avogelsgesang, Mordante, sstefan1, libcxx-commits, ldionne, mgorny, arichardson, miyuki Differential Revision: https://reviews.llvm.org/D131963
2022-09-27[libc++][NFC] Fix some standard-mandated includes commentsNikolas Klauser1-0/+2
Reviewed By: ldionne, #libc Spies: libcxx-commits Differential Revision: https://reviews.llvm.org/D134447
2022-09-06[libc++] Avoid instantiating type_trait classesNikolas Klauser1-19/+18
Use `using` aliases to avoid instantiating lots of types Reviewed By: ldionne, #libc Spies: libcxx-commits, miyuki Differential Revision: https://reviews.llvm.org/D132785
2022-09-05[libc++] Granularize __tupleNikolas Klauser1-1/+1
Reviewed By: ldionne, #libc Spies: libcxx-commits, mgorny Differential Revision: https://reviews.llvm.org/D133081
2022-09-03[NFC][libc++] Moves transitive includes location.Mark de Wever1-8/+8
As discussed in D132284 they will be moved to the end. Reviewed By: #libc, Mordante Differential Revision: https://reviews.llvm.org/D133212
2022-08-31[libc++] Reduces the number of transitive includes.Mark de Wever1-1/+1
This defines a new policy for removal of transitive includes. The goal of the policy it to make it relatively easy to remove headers when needed, but avoid breaking developers using and vendors shipping libc++. The method used is to guard transitive includes based on the C++ language version. For the upcoming C++23 we can remove headers when we want, but for other language versions we try to keep it to a minimum. In this code the transitive include of `<chrono>` is removed since D128577 introduces a header cycle between `<format>` and `<chrono>`. This cycle is indirectly required by the Standard. Our cycle dependency tool basically is a grep based tool, so it needs some hints to ignore cycles. With the input of our transitive include tests we can create a better tool. However that's out of the scope of this patch. Note the flag `_LIBCPP_REMOVE_TRANSITIVE_INCLUDES` remains unchanged. So users can still opt-out of transitives includes entirely. Reviewed By: #libc, ldionne, philnik Differential Revision: https://reviews.llvm.org/D132284
2022-08-19[libc++][NFC] Rename the constexpr macrosNikolas Klauser1-96/+96
This was discussed on Discord with the consensus that we should rename the macros. Reviewed By: ldionne, Mordante, var-const, avogelsgesang, jloser, #libc Spies: libcxx-commits Differential Revision: https://reviews.llvm.org/D131498
2022-08-14[libc++] Granularize the rest of type_traitsNikolas Klauser1-0/+1
Reviewed By: ldionne, #libc Spies: libcxx-commits, mgorny Differential Revision: https://reviews.llvm.org/D130471
2022-07-04[libc++][NFC] Replace enable_if with __enable_if_t in a few placesNikolas Klauser1-13/+3
Reviewed By: ldionne, #libc Spies: jloser, libcxx-commits Differential Revision: https://reviews.llvm.org/D128400
2022-06-27[libc++] Re-add transitive includes that had been removed since LLVM 14Louis Dionne1-0/+8
This commit re-adds transitive includes that had been removed by 4cd04d1687f1, c36870c8e79c, a83f4b9cda57, 1458458b558d, 2e2f3158c604, and 489637e66dd3. This should cover almost all the includes that had been removed since LLVM 14 and that would contribute to breaking user code when releasing LLVM 15. It is possible to disable the inclusion of these headers by defining _LIBCPP_REMOVE_TRANSITIVE_INCLUDES. The intent is that vendors will enable that macro and start fixing downstream issues immediately. We can then remove the macro (and the transitive includes) by default in a future release. That way, we will break users only once by removing transitive includes in bulk instead of doing it bit by bit a every release, which is more disruptive for users. Note 1: The set of headers to re-add was found by re-generating the transitive include test on a checkout of release/14.x, which provided the list of all transitive includes we used to provide. Note 2: Several includes of <vector>, <optional>, <array> and <unordered_map> have been added in this commit. These transitive inclusions were added when we implemented boyer_moore_searcher in <functional>. Note 3: This is a best effort patch to try and resolve downstream breakage caused since branching LLVM 14. I wasn't able to perfectly mirror transitive includes in LLVM 14 for a few headers, so I added a release note explaining it. To summarize, adding boyer_moore_searcher created a bunch of circular dependencies, so we have to break backwards compatibility in a few cases. Differential Revision: https://reviews.llvm.org/D128661
2022-06-27[libc++][NFC] Remove trailing whitespaceLouis Dionne1-7/+7
2022-06-24[libc++] P2321R2 section [tuple.tuple]. Adding C++23 constructors, ↵Hui Xie1-121/+310
assignment operators and swaps to `tuple` 1. for constructors that takes cvref variation of tuple<UTypes...>, there used to be two SFINAE helper _EnableCopyFromOtherTuple, _EnableMoveFromOtherTuple. And the implementations of these two helpers seem to slightly differ from the spec. But now, we need 4 variations. Instead of adding another two, this change refactored it to a single one _EnableCtrFromUTypesTuple, which directly maps to the spec without changing the C++11 behaviour. However, we need the helper __copy_cvref_t to get the type of std::get<i>(cvref tuple<Utypes...>) for different cvref, so I made __copy_cvref_t to be available in C++11. 2. for constructors that takes variations of std::pair, there used to be four helpers _EnableExplicitCopyFromPair, _EnableImplicitCopyFromPair, _EnableImplicitMoveFromPair, _EnableExplicitMoveFromPair. Instead of adding another four, this change refactored into two helper _EnableCtrFromPair and _BothImplicitlyConvertible. This also removes the need to use _nat 3. for const member assignment operator, since the requirement is very simple, I haven't refactored the old code but instead directly adding the new c++23 code. 4. for const swap, I pretty much copy pasted the non-const version to make these overloads look consistent 5. while doing these change, I found two of the old constructors wasn't marked constexpr for C++20 but they should. fixed them and added unit tests Reviewed By: #libc, ldionne Differential Revision: https://reviews.llvm.org/D116621
2022-06-23Revert "[libc++] P2321R2 section [tuple.tuple]. Adding C++23 constructors, ↵Hui Xie1-310/+121
assignment operators and swaps to `tuple`" When merging the changes of <type_traits> header with the commits on this header over the last month, several conflicts were mistaken resolved and the wrong branch was picked while resolving conflicts, which leads to CI failure. In order to resolve the conflicts properly with qualification CI job, this change is reverted. This reverts commit 95733a55b986e73f4d8f5314e0d4557d8ae0b226.
2022-06-23[libc++] P2321R2 section [tuple.tuple]. Adding C++23 constructors, ↵Hui Xie1-121/+310
assignment operators and swaps to `tuple` 1. for constructors that takes cvref variation of tuple<UTypes...>, there used to be two SFINAE helper _EnableCopyFromOtherTuple, _EnableMoveFromOtherTuple. And the implementations of these two helpers seem to slightly differ from the spec. But now, we need 4 variations. Instead of adding another two, this change refactored it to a single one _EnableCtrFromUTypesTuple, which directly maps to the spec without changing the C++11 behaviour. However, we need the helper __copy_cvref_t to get the type of std::get<i>(cvref tuple<Utypes...>) for different cvref, so I made __copy_cvref_t to be available in C++11. 2. for constructors that takes variations of std::pair, there used to be four helpers _EnableExplicitCopyFromPair, _EnableImplicitCopyFromPair, _EnableImplicitMoveFromPair, _EnableExplicitMoveFromPair. Instead of adding another four, this change refactored into two helper _EnableCtrFromPair and _BothImplicitlyConvertible. This also removes the need to use _nat 3. for const member assignment operator, since the requirement is very simple, I haven't refactored the old code but instead directly adding the new c++23 code. 4. for const swap, I pretty much copy pasted the non-const version to make these overloads look consistent 5. while doing these change, I found two of the old constructors wasn't marked constexpr for C++20 but they should. fixed them and added unit tests Reviewed By: #libc, ldionne Differential Revision: https://reviews.llvm.org/D116621
2022-06-17[libc++] Mark standard-mandated includes as suchNikolas Klauser1-1/+3
Reviewed By: ldionne, Mordante, #libc, saugustine Spies: saugustine, MaskRay, arichardson, mstorsjo, jloser, libcxx-commits, arphaman Differential Revision: https://reviews.llvm.org/D127953
2022-06-13[libc++] Removes unneeded includes.Mark de Wever1-5/+0
This removes all "TODO: remove these headers" comments from our headers. Note there seem to be more headers that can be removed, that will be done in separate commits. Reviewed By: #libc, ldionne Differential Revision: https://reviews.llvm.org/D127592
2022-05-28[libc++] Remove unused __functional includesNikolas Klauser1-6/+0
Reviewed By: ldionne, #libc Spies: arichardson, smeenai, libcxx-commits, arphaman Differential Revision: https://reviews.llvm.org/D126098
2022-04-07[libc++] Remove redundant __invoke_constexpr functionsNikolas Klauser1-1/+1
There are `constexpr` versions for the different `__invoke` functions, which seem to be identical other than begin `constexpr` since C++11 instead of being `constexpr` since C++20. Reviewed By: ldionne, #libc Spies: libcxx-commits Differential Revision: https://reviews.llvm.org/D123003
2022-03-30[libc++] Ensure that all public C++ headers include <__assert>Louis Dionne1-0/+1
This patch changes the requirement for getting the declaration of the assertion handler from including <__assert> to including any public C++ header of the library. Note that C compatibility headers are excluded because we don't implement all the C headers ourselves -- some of them are taken straight from the C library, like assert.h. It also adds a generated test to check it. Furthermore, this new generated test is designed in a way that will make it possible to replace almost all the existing test-generation scripts with this system in upcoming patches. Differential Revision: https://reviews.llvm.org/D122506
2022-03-17[libc++] Remove <utility> includesNikolas Klauser1-2/+0
Reviewed By: ldionne, Quuxplusone, #libc Spies: libcxx-commits, arphaman Differential Revision: https://reviews.llvm.org/D121054
2022-03-15[libc++] Define _LIBCPP_HAS_NO_PRAGMA_SYSTEM_HEADER whenever we enable ↵Louis Dionne1-0/+2
warnings in the test suite This should make CI consistent on all the compilers we support. Most of this patch is working around various warnings emitted by GCC in our code base, which are now being shown when we compile the tests. After this patch, the whole test suite should be warning free on all compilers we support and test, except for a few warnings on GCC that we silence explicitly until we figure out the proper fix for them. Differential Revision: https://reviews.llvm.org/D120684
2022-03-13[libc++] Replace _LIBCPP_HAS_NO_CONCEPTS with _LIBCPP_STD_VER > 17. NFCI.Joe Loser1-5/+5
All supported compilers that support C++20 now support concepts. So, remove `_LIB_LIBCPP_HAS_NO_CONCEPTS` in favor of `_LIBCPP_STD_VER > 17`. Similarly in the tests, remove `// UNSUPPORTED: libcpp-no-concepts`. Differential Revision: https://reviews.llvm.org/D121528
2022-03-05[libc++] Granularize <utility> includesNikolas Klauser1-1/+5
Reviewed By: ldionne, #libc Spies: EricWF, libcxx-commits, arphaman Differential Revision: https://reviews.llvm.org/D120466
2022-02-17Remove __uncvref; use __uncvref_t insteadNikolas Klauser1-4/+5
Reviewed By: Quuxplusone, #libc Spies: libcxx-commits Differential Revision: https://reviews.llvm.org/D119958
2022-02-11[libc++] Remove __functional_baseNikolas Klauser1-1/+11
Reviewed By: ldionne, Quuxplusone, #libc Spies: Mordante, mgorny, libcxx-commits, arichardson, llvm-commits, arphaman Differential Revision: https://reviews.llvm.org/D119439
2022-02-04[libc++] Normalize all our '#pragma GCC system_header', and regression-test.Arthur O'Dwyer1-1/+1
Now we'll notice if a header forgets to include this magic phrase. Differential Revision: https://reviews.llvm.org/D118800
2022-02-02[libc++] Guard bits of 598983d7 against _LIBCPP_HAS_NO_CONCEPTS.Arthur O'Dwyer1-2/+2
2022-02-02[libc++] [NFC] s/_LIBCPP_STD_VER > 17 && ↵Arthur O'Dwyer1-3/+3
!defined(_LIBCPP_HAS_NO_CONCEPTS)/!defined(_LIBCPP_HAS_NO_CONCEPTS)/ Per Discord discussion, we're normalizing on a simple `!defined(_LIBCPP_HAS_NO_CONCEPTS)` so that we can do a big search-and-replace for `!defined(_LIBCPP_HAS_NO_CONCEPTS)` back into `_LIBCPP_STD_VER > 17` when we're ready to abandon support for concept-syntax-less compilers. Differential Revision: https://reviews.llvm.org/D118748
2022-01-17[libc++][P2321R2] Add specializations of basic_common_reference and ↵Nikolas Klauser1-1/+28
common_type for tuple Add specializations of `basic_common_reference` and `common_type` for `tuple` Reviewed By: ldionne, Mordante, #libc Spies: libcxx-commits Differential Revision: https://reviews.llvm.org/D116538
2021-12-02[libc++][NFC] Update namespace comments in include/Nikolas Klauser1-2/+2
update the namspace comments in include/ Reviewed By: ldionne, #libc Spies: smeenai, libcxx-commits Differential Revision: https://reviews.llvm.org/D114947
generated by cgit v1.1 at 2024-08-03 05:48:54 +0000