aboutsummaryrefslogtreecommitdiff
path: root/libcxx/include/stack
AgeCommit message (Collapse)AuthorFilesLines
2023-12-18[libc++] Format the code base (#74334)Louis Dionne1-207/+142
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-9/+9
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++] Rename _LIBCPP_INLINE_VISIBILITY to _LIBCPP_HIDE_FROM_ABI (#74095)Louis Dionne1-30/+30
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-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-07-24[libc++] Fix template parameter naming and enforce it through ↵Nikolas Klauser1-4/+4
readability-identifier-naming Reviewed By: #libc, Mordante Spies: Mordante, aheejin, libcxx-commits Differential Revision: https://reviews.llvm.org/D156059
2023-06-10[libc++][spaceship] Implement `operator<=>` for `stack`Hristo Hristov1-0/+14
Depends on D146066 Depends on D132268 Implements parts of P1614R2 `operator<=>` for `stack` Reviewed By: #libc, Mordante Differential Revision: https://reviews.llvm.org/D146094
2023-06-05[libc++][ranges] Implement the changes to container adaptors from P1206 ↵varconst1-0/+54
(`ranges::to`): - add the `from_range_t` constructors and the related deduction guides; - add the `push_range` member function. (Note: this patch is split from https://reviews.llvm.org/D142335) Reviewed By: #libc, ldionne Differential Revision: https://reviews.llvm.org/D149829
2023-05-18[libc++][NFC] Rename iterator category checks to make it obvious that they ↵Nikolas Klauser1-4/+4
check //only// the iterator category We plan to add concepts for checking that iterators actually provide what they claim to. This is to avoid people thinking that these type traits actually check the iterator requirements in more detail. Reviewed By: ldionne, #libc Spies: Mordante, libcxx-commits, wenlei Differential Revision: https://reviews.llvm.org/D150801
2023-03-08[libc++] Granularize <type_traits> includesNikolas Klauser1-1/+2
Reviewed By: ldionne, #libc, #libc_abi Spies: #libc_vendors, smeenai, libcxx-commits Differential Revision: https://reviews.llvm.org/D145320
2023-02-15[libc++][NFC] Replace _LIBCPP_STD_VER > x with _LIBCPP_STD_VER >= xNikolas Klauser1-4/+4
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-19[libc++][format] Adds container adaptor formatters.Mark de Wever1-0/+2
Implements parts of - P2286R8 Formatting Ranges Depends on D140653 Reviewed By: ldionne, #libc Differential Revision: https://reviews.llvm.org/D141290
2022-11-05[libc++] Granularize <concept> includesNikolas Klauser1-0/+1
Reviewed By: ldionne, #libc Spies: libcxx-commits Differential Revision: https://reviews.llvm.org/D137283
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-03[NFC][libc++] Moves transitive includes location.Mark de Wever1-4/+4
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-06-27[libc++] Re-add transitive includes that had been removed since LLVM 14Louis Dionne1-0/+4
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-17[libc++] Mark standard-mandated includes as suchNikolas Klauser1-0/+4
Reviewed By: ldionne, Mordante, #libc, saugustine Spies: saugustine, MaskRay, arichardson, mstorsjo, jloser, libcxx-commits, arphaman Differential Revision: https://reviews.llvm.org/D127953
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-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-01-06[libc++] Implement P1425R4 (Iterator pair constructors for std::stack and ↵Nikolas Klauser1-1/+42
std::queue) Implement P1425R4 Reviewed By: Quuxplusone, #libc, Mordante Spies: Mordante, jloser, libcxx-commits, arichardson Differential Revision: https://reviews.llvm.org/D115977
2022-01-04[libc++] Add the version header to all headers.Mark de Wever1-0/+1
Some headers which require the version header depend on other headers to provide it. Include the version header in all top-level headers to make sure a header cleanup can't remove the version header. Note this doesn't add the version header to the c headers. Reviewed By: #libc, Quuxplusone, ldionne Differential Revision: https://reviews.llvm.org/D116172
2021-11-17[runtimes][NFC] Remove filenames at the top of the license noticeLouis Dionne1-1/+1
We've stopped doing it in libc++ for a while now because these names would end up rotting as we move things around and copy/paste stuff. This cleans up all the existing files so as to stop the spreading as people copy-paste headers around.
2021-09-08[libc++][NFC] Rename _EnableIf to __enable_if_t for consistencyLouis Dionne1-6/+6
In other places in the code, we use lowercase spelling for things that are not available in prior standards. Differential Revision: https://reviews.llvm.org/D109435
2021-09-08[libc++] Use enable_if_t instead of _EnableIfLouis Dionne1-3/+3
I just ran into a compiler error involving __bind_back and some overloads that were being disabled with _EnableIf. I noticed that the error message was quite bad and did not mention the reason for the overload being excluded. Specifically, the error looked like this: candidate template ignored: substitution failure [with _Args = <ContiguousView>]: no member named '_EnableIfImpl' in 'std::_MetaBase<false>' Instead, when using enable_if or enable_if_t, the compiler is clever and can produce better diagnostics, like so: candidate template ignored: requirement 'is_invocable_v< std::__bind_back_op<1, std::integer_sequence<unsigned long, 0>>, std::ranges::views::__transform::__fn &, std::tuple<PlusOne> &, ContiguousView>' was not satisfied [with _Args = <ContiguousView>] Basically, it tries to do a poor man's implementation of concepts, which is already a lot better than simply complaining about substitution failure. Hence, this commit uses enable_if_t instead of _EnableIf whenever possible. That is both more straightforward than using the internal helper, and also leads to better error messages in those cases. I understand the motivation for _EnableIf's implementation was to improve compile-time performance, however I believe striving to improve error messages is even more important for our QOI, hence this patch. Furthermore, it is unclear that _EnableIf actually improved compile-time performance in any noticeable way (see discussion in the review for details). Differential Revision: https://reviews.llvm.org/D108216
2021-08-18[libc++] Remove workarounds for the lack of deduction guides in C++17Louis Dionne1-1/+1
All supported compilers have supported deduction guides in C++17 for a while, so this isn't necessary anymore. Differential Revision: https://reviews.llvm.org/D108213
2021-07-01[libcxx][functional][modular] splices <functional> into modular headersChristopher Di Bella1-0/+1
Differential Revision: https://reviews.llvm.org/D104942
2021-06-24[libcxx][modularisation] moves <utility> content out of <type_traits>Christopher Di Bella1-0/+1
Moves: * `std::move`, `std::forward`, `std::declval`, and `std::swap` into `__utility/${FUNCTION_NAME}`. * `std::swap_ranges` and `std::iter_swap` into `__algorithm/${FUNCTION_NAME}` Differential Revision: https://reviews.llvm.org/D103734
2021-06-18[libc++] [P1518R2] Better CTAD behavior for containers with allocators.Arthur O'Dwyer1-1/+1
P1518 does the following in C++23 but we'll just do it in C++17 as well: - Stop requiring `Alloc` to be an allocator on some container-adaptor deduction guides - Stop deducing from `Allocator` on some sequence container constructors - Stop deducing from `Allocator` on some other container constructors (libc++ already did this) The affected constructors are the "allocator-extended" versions of constructors where the non-allocator arguments are already sufficient to deduce the allocator type. For example, std::pmr::vector<int> v1; std::vector v2(v1, std::pmr::new_delete_resource()); std::stack s2(v1, std::pmr::new_delete_resource()); Differential Revision: https://reviews.llvm.org/D97742
2021-04-20[libc++] NFC: Normalize `#endif //` comment indentationLouis Dionne1-4/+4
2021-03-29[libc++] Use _EnableIf and __iter_value_type consistently. NFCI.Arthur O'Dwyer1-17/+9
Specifically, use these metafunctions consistently in areas that are about to be affected by P1518R2's changes. This is the NFCI part of https://reviews.llvm.org/D97742 . The functional-change part is still waiting for P1518R2 to be officially merged into the working draft.
2019-05-29[NFC][libcxx] Remove trailing whitespaceLouis Dionne1-5/+5
It's incredibly annoying when trying to create diffs llvm-svn: 361981
2019-01-19Update more file headers across all of the LLVM projects in the monorepoChandler Carruth1-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
2018-05-22Deduction guides for the container adaptors - queue, stack, and priority_queueMarshall Clow1-0/+22
llvm-svn: 332927
2018-01-24Implement LWG2783: stack::emplace() and queue::emplace() should return ↵Marshall Clow1-1/+1
decltype(auto) llvm-svn: 323385
2017-11-15First part of P0600 - '[[nodiscard] in the standard library'. Mark the ↵Marshall Clow1-1/+1
'empty()' methods of all the containers as nodiscard. If you're calling empty() w/o looking at the result, you probably meanto to call 'clear()'. c++2a only llvm-svn: 318269
2017-04-18Cleanup _LIBCPP_HAS_NO_<c++11-feature> macro uses in std::stack.Eric Fiselier1-17/+16
llvm-svn: 300602
2017-01-24Change the return type of emplace_[front|back] back to void when building ↵Marshall Clow1-1/+6
with C++14 or before. Resolves PR31680. llvm-svn: 292990
2017-01-04[NFC] Rename _LIBCPP_TYPE_VIS_ONLY to _LIBCPP_TEMPLATE_VISEric Fiselier1-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
2016-07-21Implement P0084r2. Changing emplace return types.Eric Fiselier1-3/+3
llvm-svn: 276230
2016-04-21Add is_swappable/is_nothrow_swappable traitsEric Fiselier1-2/+5
llvm-svn: 267079
2016-03-14Implement LWG#2566: Requirements on the first template parameter of ↵Marshall Clow1-1/+2
container adaptors llvm-svn: 263450
2015-02-18Move the default template arguments into the forward declarations for the ↵Marshall Clow1-2/+2
container adapters: stack and queue. References PR#22605. llvm-svn: 229708
2013-08-12Nico Rieck: this patch series fixes visibility issues on Windows as ↵Howard Hinnant1-3/+3
explained in <http://lists.cs.uiuc.edu/pipermail/cfe-dev/2013-August/031214.html>. llvm-svn: 188192
2013-03-06No functionality change at this time. I've split _LIBCPP_VISIBLE up into ↵Howard Hinnant1-3/+3
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
2012-09-14Dimitry Andric: many visibility fixes. Howard: Much appreciated. Can you ↵Howard Hinnant1-1/+3
send me a patch to CREDITS.TXT? llvm-svn: 163862
2011-10-17Windows support by Ruben Van Boxem.Howard Hinnant1-0/+2
llvm-svn: 142235
2011-06-30_STD -> _VSTD to avoid macro clash on windowsHoward Hinnant1-8/+8
llvm-svn: 134190
2011-06-04noexcept for <stack>. This completes noexcept for Chapter 23 [containers].Howard Hinnant1-10/+39
llvm-svn: 132652
2010-11-16license changeHoward Hinnant1-2/+2
llvm-svn: 119395
2010-09-23visibility-decoration.Howard Hinnant1-10/+30
llvm-svn: 114671
generated by cgit v1.1 at 2024-09-09 05:57:01 +0000