util: add ranges.h to emulate c++20 std::ranges#4622
Merged
Conversation
PastaPastaPasta
force-pushed
the
ranges-and-more
branch
from
b2fb5d2 to
31bc445
Compare
UdjinM6
requested changes
Dec 18, 2021
|
LGTM but let's maybe split this in 2 PRs if possible:
|
PastaPastaPasta
force-pushed
the
ranges-and-more
branch
from
2ecbdba to
c32b973
Compare
PastaPastaPasta
changed the title
gades
pushed a commit
to cosanta/cosanta-core
that referenced
this pull request
Nov 7, 2023
* refactor: introduce ranges.h for prettier std algo. Also use it in dash core * fix formatting, use ranges instead of std * remove commented out code * introduce ranges find_if_opt, count_if, find_if. Use them all, and more * use std::accumulate * capture everything so that threadsaftey analysis is happy * fix linter * fix linter * remove pessimizing move
gades
pushed a commit
to piratecash/pirate
that referenced
this pull request
Dec 9, 2023
* refactor: introduce ranges.h for prettier std algo. Also use it in dash core * fix formatting, use ranges instead of std * remove commented out code * introduce ranges find_if_opt, count_if, find_if. Use them all, and more * use std::accumulate * capture everything so that threadsaftey analysis is happy * fix linter * fix linter * remove pessimizing move
This was referenced Nov 2, 2024
PastaPastaPasta
added a commit
that referenced
this pull request
Nov 4, 2024
…ammy`) 1592a0f ci: update containers and CI to use Ubuntu 22.04 LTS (`jammy`) (Kittywhiskers Van Gogh) decbd05 ci: stop running `check-symbols` during builds (Kittywhiskers Van Gogh) Pull request description: ## Motivation While some aspects of C++20 are supported by GCC 9.3 (the version shipped with `focal`, [source](https://packages.ubuntu.com/focal/g++)), P0896R4 ("The One Ranges Proposal") is not ([source](https://en.cppreference.com/w/cpp/compiler_support)), required for moving away from [dash#4622](#4622) to adopt `std::ranges` and for backporting PRs like [bitcoin#28687](bitcoin#28687). They're supported from GCC 10.1 onwards ([source](https://stackoverflow.com/questions/56118941/do-we-have-c20-ranges-library-in-gcc-9/56118997#56118997)) and the next available LTS, `jammy`, currently ships with GCC 11.2 ([source](https://packages.ubuntu.com/jammy/g++)). As we're now using Guix to build our releases, there shouldn't be any adverse effects from our containers having a higher version of `glibc`. Additionally, upstream uses 24.04 (`noble`) for their build images ([source](https://github.com/bitcoin/bitcoin/blob/a2317e27b7fb86df4e32cd1674c06e09cb808248/ci/test/00_setup_env_native_tsan.sh#L10)) and `jammy` to determine the minimum version to CMake ([source](https://github.com/bitcoin/bitcoin/blob/a2317e27b7fb86df4e32cd1674c06e09cb808248/CMakeLists.txt#L5-L6)) (for reference, `focal` ships with CMake 3.16, [source](https://packages.ubuntu.com/focal/cmake)). ## Additional Information * Builds will no longer run `check-symbols` (and the option to do so, `RUN_SYMBOL_TESTS` has been removed) as portable builds (builds expected for distributions) are built with Guix, which pins its version of `glibc` ([source](https://github.com/dashpay/dash/blob/396573d09cff5c65b2e3b4ba965185ac532b8b5c/contrib/guix/manifest.scm#L152), currently 2.28), runs `check-symbols` ([source](https://github.com/dashpay/dash/blob/396573d09cff5c65b2e3b4ba965185ac532b8b5c/contrib/guix/libexec/build.sh#L304-L305)), which in turn make sure that it doesn't contain symbols expected in versions higher than `glibc` 2.31 ([source](https://github.com/dashpay/dash/blob/396573d09cff5c65b2e3b4ba965185ac532b8b5c/contrib/devtools/symbol-check.py#L38-L42)). Upstream does not use `check-symbols` during their builds nor do we have a reason to (as we no longer using Gitian). * CI build failures w.r.t. `pthread_yield` ([build](https://github.com/dashpay/dash/actions/runs/11645989968/job/32437272177?pr=6379#step:7:3136), [build](https://github.com/dashpay/dash/actions/runs/11645989968/job/32430165640#step:7:3157)) should be resolved by rebuilding `bdb4` (see [bitcoin#26423](bitcoin#26423 (comment))). This problem has only been observed on GitHub CI and locally (the latter resolved by rebuilding depends, I use a separate target triple for testing, `x86_64-jammy-linux-gnu`), GitLab CI has not observed such failures ([build](https://gitlab.com/dashpay/dash/-/jobs/8253943710)). ## Breaking changes None expected. ## Checklist - [x] I have performed a self-review of my own code - [x] I have commented my code, particularly in hard-to-understand areas **(note: N/A)** - [x] I have added or updated relevant unit/integration/functional/e2e tests **(note: N/A)** - [x] I have made corresponding changes to the documentation **(note: N/A)** - [x] I have assigned this pull request to a milestone _(for repository code-owners and collaborators only)_ ACKs for top commit: UdjinM6: utACK 1592a0f knst: utACK 1592a0f PastaPastaPasta: utACK 1592a0f Tree-SHA512: cbe6505211246c711dc0fd8645b8a4c6123b5ac163341dca4c686f8905a630c57d483a91a6e29bd9e23bac79d774e339181d2cb17bb3affeb5902e5f548ffa54
PastaPastaPasta
added a commit
that referenced
this pull request
Nov 4, 2024
…as c0b716f2 f18e839 build: drop symlinks in immer subtree (Kittywhiskers Van Gogh) d761111 build: fix gitian builds (Kittywhiskers Van Gogh) a9f46b3 Squashed 'src/immer/' changes from 9cb6a5a845..5875f7739a (Kittywhiskers Van Gogh) e4ee302 revert: fix gitian builds (Kittywhiskers Van Gogh) fb00300 revert: drop symlinks in immer subtree (Kittywhiskers Van Gogh) Pull request description: ## Additional Information * Dependency for #6380 #6380 will be using `std::ranges` as a replacement for [dash#4622](#4622) and currently, it will fail to compile due to the current version of `immer` (last updated two years ago in #4911) not meeting constraints ([source](https://en.cppreference.com/w/cpp/language/constraints)) set by `std::ranges` (see below). ``` ./evo/deterministicmns.h:243:16: error: no matching function for call to object of type 'const __count_if_fn' return ranges::count_if(mnMap, [](const auto& p) { return IsMNValid(*p.second); }); ^~~~~~~~~~~~~~~~ /usr/bin/../lib/gcc/x86_64-linux-gnu/11/../../../../include/c++/11/bits/ranges_algo.h:331:7: note: candidate template ignored: substitution failure [with _Range = const MnMap &, _Proj = identity, _Pred = (lambda at ./evo/deterministicmns.h:243:40)]: constraints not satisfied for alias template 'range_difference_t' [with _Range = const immer::map<uint256, std::shared_ptr<const CDeterministicMN>, CDeterministicMNList::ImmerHasher> &] operator()(_Range&& __r, _Pred __pred, _Proj __proj = {}) const ^ /usr/bin/../lib/gcc/x86_64-linux-gnu/11/../../../../include/c++/11/bits/ranges_algo.h:316:7: note: candidate function template not viable: requires at least 3 arguments, but 2 were provided operator()(_Iter __first, _Sent __last, ^ ``` This has been resolved by updating `immer` to the latest available release, [v0.8.1](https://github.com/arximboldi/immer/releases/tag/v0.8.1). Expected subtree hash **without changes** are `a5ded361aec714bc74149909c5e1984c10ab132c4c539c63fe57362dccd95556` (see [here](#6323 (review)) for verification instructions). ## Breaking Changes None expected. ## Checklist - [x] I have performed a self-review of my own code **(note: N/A)** - [x] I have commented my code, particularly in hard-to-understand areas **(note: N/A)** - [x] I have added or updated relevant unit/integration/functional/e2e tests **(note: N/A)** - [x] I have made corresponding changes to the documentation **(note: N/A)** - [x] I have assigned this pull request to a milestone _(for repository code-owners and collaborators only)_ ACKs for top commit: PastaPastaPasta: utACK f18e839 UdjinM6: utACK f18e839 Tree-SHA512: 99d1b577eb4cf3fcc3ebfd28f19006700f085d23ccdabe802a2aa5844e4b39314347b0c0e49a352c5fc034d6584a0109edf08fa3c0846514967f1fb16e7f127a
5 tasks
5 tasks
PastaPastaPasta
added a commit
that referenced
this pull request
Mar 12, 2026
…polyfills (`util/std23.h`) and helpers (`util/helpers.h`) 1c8260c refactor: add `util::to_string(bool)` for convenience (Kittywhiskers Van Gogh) dec2766 refactor: merge `util/ranges.h` and `util/pointer.h` to `util/helpers.h` (Kittywhiskers Van Gogh) f57edb5 refactor: use `std23::ranges::fold_left` in Dash-specific code (Kittywhiskers Van Gogh) 4c30be5 util: add polyfill for `std::ranges::fold_left` (Kittywhiskers Van Gogh) 5dc17fc refactor: use `std23::ranges::contains` in Dash-specific code (Kittywhiskers Van Gogh) 43e64ed util: add polyfill for `std::ranges::contains` (Kittywhiskers Van Gogh) 79f0711 refactor: replace `irange::range` with thin `std::views::iota` wrapper (Kittywhiskers Van Gogh) 58a9a3d refactor: switch from `irange(min, max)` to `std::views::iota(min, max)` (Kittywhiskers Van Gogh) 6bee408 refactor: distinguish between custom helpers and polyfills (Kittywhiskers Van Gogh) f1d5d30 refactor: move `enumerate` to C++23 polyfill, mirror namespace structure (Kittywhiskers Van Gogh) aa12106 refactor: rename `ToUnderlying()` to match C++23 convention (Kittywhiskers Van Gogh) 2ca0fd7 fix: enum bound check in GetSimulatedErrorRate (Kittywhiskers Van Gogh) Pull request description: ## Motivation The upgrade to C++20 ([dash#6380](#6380)) allowed us to drop most of our polyfills meant as bridge from C++17, though we still have utils beyond the ones inherited from upstream that have accumulated over time, most of them, seeking to bridge C++23 features while others are entirely custom or serve as convenience functions or thin wrappers. Some of them include: * [dash#4622](#4622) for `util/ranges.h` (mostly now an alias to [`std::ranges`](https://en.cppreference.com/w/cpp/ranges.html) after C++20 migration except for `find_if_opt`, which is custom) * [dash#4788](#4788) for `util/irange.h` (equivalent to [`std::views::iota`](https://en.cppreference.com/w/cpp/ranges/iota_view.html), introduced in C++20) * [dash#5059](#5059) for `util/enumerate.h` (equivalent to [`std::views::enumerate`](http://en.cppreference.com/w/cpp/ranges/enumerate_view.html), introduced in C++23) * [dash#5210](#5210) for `util/underlying.h` (equivalent to [`std::to_underlying`](https://en.cppreference.com/w/cpp/utility/to_underlying.html), introduced in C++23) * 0a4e726 for `util/pointer.h` (custom `std::shared_ptr` helper) This pull requests compacts all of those helpers into two files: * `util/helpers.h` (custom helpers, replacing `util/irange.h`, `util/pointer.h`, `util/ranges.h`) * `util/std23.h` (polyfill for C++23, replacing `util/enumerate.h` and `util/underlying.h`) And additionally, introduces additional capabilities utilised in Dash-specific code: * `std23::ranges::contains` (equivalent to [`std::ranges::contains`](https://en.cppreference.com/w/cpp/algorithm/ranges/contains.html)) * `std23::ranges::fold_left` (equivalent to [`std::ranges::fold_left`](https://en.cppreference.com/w/cpp/algorithm/ranges/fold_left.html)) * `util::to_string(bool)` (equivalent to `value ? "true" : "false"`) ## Additional Information * `ToUnderlying()` needed to be renamed to `to_underlying()` to match with the standard library naming so we can discontinue the polyfill easily when we migrate to C++23 by just going `s/std23/std/g`. * While `iranges::range` is equivalent to `std::views::iota`, the latter requires both min and max to be of the same type but literal `0` has a type incompatible with `size_t`, requiring `size_t{0}` to compile. As propagation of these changes for each instance is bothersome, `util::irange()` exists as a thin wrapper that wraps the literal around the type for `max` ## Breaking Changes None expected. ## Checklist - [x] I have performed a self-review of my own code - [x] I have commented my code, particularly in hard-to-understand areas - [x] I have added or updated relevant unit/integration/functional/e2e tests - [x] I have made corresponding changes to the documentation **(note: N/A)** - [x] I have assigned this pull request to a milestone _(for repository code-owners and collaborators only)_ ACKs for top commit: PastaPastaPasta: utACK 1c8260c; seems reasonable UdjinM6: utACK 1c8260c Tree-SHA512: 82f4b74f304d8680ddb03a923843905a470b374c034284dbe6a013d19e67a769743965f710c5267751742488961907d346ce721d01029cffa543178fd560dcc1
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
No description provided.