aboutsummaryrefslogtreecommitdiff
path: root/libcxx/include/__numeric
AgeCommit message (Collapse)AuthorFilesLines
2024-06-18[libc++][NFC] Remove unnecessary parens in static_asserts (#95605)Nikolas Klauser1-7/+7
These were required a long time ago due to `static_assert` not actually being available in C++03. Now `static_assert` is simply mapped to `_Static_assert` in C++03, making the additional parens unnecessary.
2024-06-12[libc++] Remove unnecessary #ifdef guards around PSTL implementation details ↵Louis Dionne1-12/+13
(#95268) We want the PSTL implementation details to be available regardless of the Standard mode or whether the experimental PSTL is enabled. This patch guards the inclusion of the PSTL to the top-level headers that define the public API in `__numeric` and `__algorithm`.
2024-06-12[libc++] Overhaul the PSTL dispatching mechanism (#88131)Louis Dionne1-132/+66
The experimental PSTL's current dispatching mechanism was designed with flexibility in mind. However, while reviewing the in-progress OpenMP backend, I realized that the dispatching mechanism based on ADL and default definitions in the frontend had several downsides. To name a few: 1. The dispatching of an algorithm to the back-end and its default implementation is bundled together via `_LIBCPP_PSTL_CUSTOMIZATION_POINT`. This makes the dispatching really confusing and leads to annoyances such as variable shadowing and weird lambda captures in the front-end. 2. The distinction between back-end functions and front-end algorithms is not as clear as it could be, which led us to call one where we meant the other in a few cases. This is bad due to the exception requirements of the PSTL: calling a front-end algorithm inside the implementation of a back-end is incorrect for exception-safety. 3. There are two levels of back-end dispatching in the PSTL, which treat CPU backends as a special case. This was confusing and not as flexible as we'd like. For example, there was no straightforward way to dispatch all uses of `unseq` to a specific back-end from the OpenMP backend, or for CPU backends to fall back on each other. This patch rewrites the backend dispatching mechanism to solve these problems, but doesn't touch any of the actual implementation of algorithms. Specifically, this rewrite has the following characteristics: - There is a single level of backend dispatching, however partial backends can be stacked to provide a full implementation of the PSTL. The two-level dispatching that was used for CPU-based backends is handled by providing CPU-based basis operations as simple helpers that can easily be reused when defining any PSTL backend. - The default definitions for algorithms are separated from their dispatching logic. - The front-end is thus simplified a whole lot and made very consistent for all algorithms, which makes it easier to audit the front-end for things like exception-correctness, appropriate forwarding, etc. Fixes #70718
2024-05-27[libc++][pstl] Merge all frontend functions for the PSTL (#89219)Louis Dionne2-115/+80
This is an intermediate step towards the PSTL dispatching mechanism rework. It will make it a lot easier to track the upcoming front-end changes. After the rework, there are basically no implementation details in the front-end, so the definition of each algorithm will become much simpler. Otherwise, it wouldn't make sense to define all the algorithms in the same header.
2024-05-08[libc++] Implement std::gcd using the binary version (#77747)serge-sans-paille1-2/+42
The binary version is four times faster than current implementation in my setup, and generally considered a better implementation. Code inspired by https://en.algorithmica.org/hpc/algorithms/gcd/ which itself is inspired by https://lemire.me/blog/2013/12/26/fastest-way-to-compute-the-greatest-common-divisor/ Fix #77648
2024-04-24[libc++] Makes saturation functions privately available. (#89503)Mark de Wever1-6/+35
These functions are useful in the implementation of the time zone database. So expose them with private names. The functions could be exposed before C++ 20, but since libc++ is mostly C++ 17 complete it seems less useful to allow earlier. --------- Co-authored-by: Hristo Hristov <zingam@outlook.com>
2024-04-17[libc++][pstl] Promote CPU backends to top-level backends (#88968)Louis Dionne1-1/+1
This patch removes the two-level backend dispatching mechanism we had in the PSTL. Instead of selecting both a PSTL backend and a PSTL CPU backend, we now only select a top-level PSTL backend. This greatly simplifies the PSTL configuration layer. While this patch technically removes some flexibility from the PSTL configuration mechanism because CPU backends are not considered separately, it opens the door to a much more powerful configuration mechanism based on chained backends in a follow-up patch. This is a step towards overhauling the PSTL dispatching mechanism.
2024-04-17[libc++] Add missing iterator requirement checks in the PSTL (#88127)Louis Dionne2-0/+9
Also add tests for those, and add a few missing requirements to testing iterators in the test suite.
2024-04-04[libc++][NFC] Make __desugars_to a variable template and rename the header ↵Nikolas Klauser1-1/+1
to desugars_to.h (#87337) This improves compile times and memory usage slightly and removes some boilerplate.
2024-02-29[libc++] Clean up includes of <__assert> (#80091)Louis Dionne1-0/+1
Originally, we used __libcpp_verbose_abort to handle assertion failures. That function was declared from all public headers. Since we don't use that mechanism anymore, we don't need to declare __libcpp_verbose_abort from all public headers, and we can clean up a lot of unnecessary includes. This patch also moves the definition of the various assertion categories to the <__assert> header, since we now rely on regular IWYU for these assertion macros. rdar://105510916
2024-02-17[libc++] simplify the midpoint function (#81717)rilysh1-8/+10
Right now we've a nested ternary for the midpoint function, but this can be simplified a bit more, using if statements. This also slightly increases the readability of that function.
2024-01-25[libc++] Fix missing and incorrect push/pop macros (#79204)Louis Dionne5-0/+25
We recently noticed that the unwrap_iter.h file was pushing macros, but it was pushing them again instead of popping them at the end of the file. This led to libc++ basically swallowing any custom definition of these macros in user code: #define min HELLO #include <algorithm> // min is not HELLO anymore, it's not defined While investigating this issue, I noticed that our push/pop pragmas were actually entirely wrong too. Indeed, instead of pushing macros like `move`, we'd push `move(int, int)` in the pragma, which is not a valid macro name. As a result, we would not actually push macros like `move` -- instead we'd simply undefine them. This led to the following code not working: #define move HELLO #include <algorithm> // move is not HELLO anymore Fixing the pragma push/pop incantations led to a cascade of issues because we use identifiers like `move` in a large number of places, and all of these headers would now need to do the push/pop dance. This patch fixes all these issues. First, it adds a check that we don't swallow important names like min, max, move or refresh as explained above. This is done by augmenting the existing system_reserved_names.gen.py test to also check that the macros are what we expect after including each header. Second, it fixes the push/pop pragmas to work properly and adds missing pragmas to all the files I could detect a failure in via the newly added test. rdar://121365472
2024-01-22[libc++][numeric] P0543R3: Saturation arithmetic (#77967)Hristo Hristov1-0/+110
Implements: https://wg21.link/P0543R3 - https://eel.is/c++draft/numeric.sat Additional references: - Division: https://eel.is/c++draft/expr.mul#4 - Arithmetic conversions: https://eel.is/c++draft/expr.arith.conv#1 - Clang builtins: https://clang.llvm.org/docs/LanguageExtensions.html#builtin-functions Depends on: https://github.com/llvm/llvm-project/pull/78086 --------- Co-authored-by: Zingam <zingam@outlook.com> Co-authored-by: Mark de Wever <zar-rpg@xs4all.nl>
2024-01-20[libc++][hardening] Categorize assertions that produce incorrect results ↵Konstantin Varlamov1-1/+1
(#77183) Introduce a new `argument-within-domain` category that covers cases where the given arguments make it impossible to produce a correct result (or create a valid object in case of constructors). While the incorrect result doesn't create an immediate problem within the library (like e.g. a null pointer dereference would), it always indicates a logic error in user code and is highly likely to lead to a bug in the program once the value is used.
2023-12-20[libc++] Fix ability to explicitly instantiate std::midpoint (#74217)Sanjay Marreddi1-6/+2
std::midpoint is specified by having a pointer overload in [numeric.ops.midpoint]. With the way the pointer overload is specified, users can expect that calling std::midpoint as `std::midpoint<T>(a, b)` should work, but it didn't in libc++ due to the way the pointer overload was specified. Fixes #67046
2023-12-18[libc++] Format the code base (#74334)Louis Dionne13-249/+196
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 Dionne11-24/+24
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 Dionne13-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-11-23[libc++] Unify __is_trivial_equality_predicate and ↵Anton Rydahl1-1/+1
__is_trivial_plus_operation into __desugars_to (#68642) When working on an OpenMP offloading backend for standard parallel algorithms (https://github.com/llvm/llvm-project/pull/66968) we noticed the need of a generalization of `__is_trivial_plus_operation`. This patch merges `__is_trivial_equality_predicate` and `__is_trivial_plus_operation` into `__desugars_to`, and in the future we might extend the latter to support other binary operations as well. Co-authored-by: Louis Dionne <ldionne.2@gmail.com>
2023-10-06[libc++][PSTL] Overhaul exceptions handlingNikolas Klauser2-21/+103
This makes exception handling a lot simpler, since we don't have to convert any exceptions this way. Is also properly handles all the user-thrown exceptions. Reviewed By: ldionne, #libc Spies: arichardson, mstorsjo, libcxx-commits Differential Revision: https://reviews.llvm.org/D154238
2023-10-04[libc++] Explicitly pass execution policies to ↵Louis Dionne1-2/+2
_LIBCPP_PSTL_CUSTOMIZATION_POINT (#68238) The _LIBCPP_PSTL_CUSTOMIZATION_POINT macro was assuming that the policy was called _RawPolicy and referencing it by name. It happened to always work but this was definitely accidental and an oversight in the original implementation. This patch fixes that by passing the policy to the macro explicitly. Noticed while reviewing #66968.
2023-07-12[libc++][PSTL] Add a GCD backendNikolas Klauser1-1/+2
Reviewed By: ldionne, #libc Spies: arichardson, mgrang, krytarowski, libcxx-commits, h-vetinari Differential Revision: https://reviews.llvm.org/D151717
2023-07-06Fixing conflicting macro definitions between curses.h and the standard library.Nicole Rabjohn5-0/+25
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-06-28[libc++][hardening][NFC] Introduce `_LIBCPP_ASSERT_UNCATEGORIZED`.varconst1-1/+1
Replace most uses of `_LIBCPP_ASSERT` with `_LIBCPP_ASSERT_UNCATEGORIZED`. This is done as a prerequisite to introducing hardened mode to libc++. The idea is to make enabling assertions an opt-in with (somewhat) fine-grained controls over which categories of assertions are enabled. The vast majority of assertions are currently uncategorized; the new macro will allow turning on `_LIBCPP_ASSERT` (the underlying mechanism for all kinds of assertions) without enabling all the uncategorized assertions (in the future; this patch preserves the current behavior). Differential Revision: https://reviews.llvm.org/D153816
2023-06-01[libc++][PSTL] Implement std::reduce and std::transform_reduceNikolas Klauser3-2/+175
Reviewed By: ldionne, #libc Spies: libcxx-commits, miyuki Differential Revision: https://reviews.llvm.org/D150736
2023-02-15[libc++][NFC] Replace _LIBCPP_STD_VER > x with _LIBCPP_STD_VER >= xNikolas Klauser12-21/+21
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-21[libc++] Granularize <type_traits> includes in <bit>, <numbers> and <coroutine>Nikolas Klauser2-2/+16
`<coroutine>` seems to be new enough to not be a huge problem. Reviewed By: Mordante, #libc Spies: libcxx-commits, ChuanqiXu Differential Revision: https://reviews.llvm.org/D140600
2022-12-23[libc++] Add custom clang-tidy checksNikolas Klauser1-3/+3
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-06[libc++] Avoid instantiating type_trait classesNikolas Klauser1-4/+4
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-08-19[libc++][NFC] Rename the constexpr macrosNikolas Klauser11-23/+23
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-13[libc++] Add a bunch of missing _LIBCPP_HIDE_FROM_ABINikolas Klauser1-2/+2
Reviewed By: ldionne, Mordante, var-const, huixie90, #libc Spies: jloser, libcxx-commits, arichardson, miyuki Differential Revision: https://reviews.llvm.org/D129968
2022-07-08[libc++] Make parameter names consistent and enforce the naming style using ↵Nikolas Klauser1-3/+3
readability-identifier-naming Ensure that parameter names have the style `__lower_case` Reviewed By: ldionne, #libc Spies: aheejin, sstefan1, libcxx-commits, miyuki Differential Revision: https://reviews.llvm.org/D129051
2022-03-01[libc++] Revert "Protect users from relying on detail headers" & related changesLouis Dionne13-13/+0
This commit reverts 5aaefa51 (and also partly 7f285f48e77 and b6d75682f9, which were related to the original commit). As landed, 5aaefa51 had unintended consequences on some downstream bots and didn't have proper coverage upstream due to a few subtle things. Implementing this is something we should do in libc++, however we'll first need to address a few issues listed in https://reviews.llvm.org/D106124#3349710. Differential Revision: https://reviews.llvm.org/D120683
2022-02-26[libcxx][modules] protects users from relying on detail headersChristopher Di Bella13-0/+13
libc++ has started splicing standard library headers into much more fine-grained content for maintainability. It's very likely that outdated and naive tooling (some of which is outside of LLVM's scope) will suggest users include things such as <__ranges/access.h> instead of <ranges>, and Hyrum's law suggests that users will eventually begin to rely on this without the help of tooling. As such, this commit intends to protect users from themselves, by making it a hard error for anyone outside of the standard library to include libc++ detail headers. Differential Revision: https://reviews.llvm.org/D106124
2022-02-16[libc++] Move everything related solely to _LIBCPP_ASSERT to its own fileLouis Dionne1-1/+1
This is the first step towards disentangling the debug mode and assertions in libc++. This patch doesn't make any functional change: it simply moves _LIBCPP_ASSERT-related stuff to its own file so as to make it clear that libc++ assertions and the debug mode are different things. Future patches will make it possible to enable assertions without enabling the debug mode. Differential Revision: https://reviews.llvm.org/D119769
2022-02-04[libc++] Normalize all our '#pragma GCC system_header', and regression-test.Arthur O'Dwyer2-2/+2
Now we'll notice if a header forgets to include this magic phrase. Differential Revision: https://reviews.llvm.org/D118800
2021-12-01[libcxx][modularisation] modularises <numeric> headerChristopher Di Bella13-0/+781
Differential Revision: https://reviews.llvm.org/D114836