-
Notifications
You must be signed in to change notification settings - Fork 38.7k
refactor: Remove Span operator==, Use std::ranges::equal #29071
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
|
The following sections might be updated with supplementary metadata relevant to reviewers and maintainers. Code CoverageFor detailed information about the code coverage, see the test coverage report. ReviewsSee the guideline for information on the review process.
If your review is incorrectly listed, please react with 👎 to this comment and the bot will ignore it on the next update. ConflictsReviewers, this pull request conflicts with the following ones:
If you consider this pull request important, please also help to review the conflicting pull requests. Ideally, start with the one that should be merged first. |
fabd742 to
1ff0c38
Compare
1ff0c38 to
56c9e51
Compare
|
Looks like this also fails on macOS on GHA. Does anyone know what version(s) of clang can be expected to be available on macOS normally? |
Pretty sure that job should be rerun, because it's failing in the brew install stage. |
GIven our minimum supported macOS (11.x), you could run anything from Xcode 12.5+ onwards, which is roughly LLVM/Clang 12+. Although I'd expect most users compiling from source on macOS, would be using a much more recent Xcode, so likely Clang ~14+ at least. Also, anyone should be able to install and run the latest LLVM/Clang via brew. |
56c9e51 to
adaeeb2
Compare
adaeeb2 to
c45d3b7
Compare
c45d3b7 to
05804fb
Compare
fafc3a6 to
fabcd0c
Compare
|
🚧 At least one of the CI tasks failed. Make sure to run all tests locally, according to the Possibly this is due to a silent merge conflict (the changes in this pull request being Leave a comment here, if you need help tracking down a confusing failure. |
hodlinator
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ACK fabcd0c4fe44e3bc2d6a59f2839f459fd5c81171
fabcd0c to
fa69fba
Compare
hodlinator
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Untested re-ACK fa69fba751079ee6042daceb88bc8f8ad3f3de96
git range-diff master fabcd0c fa69fba reveals pure whitespace change.
stickies-v
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Approach ACK
Replace std::equal with std::ranges::equal, because it allows for shorter code, because no pointers or iterators have to be passed explicitly.
fa69fba to
fad0cf6
Compare
|
Force pushed for iwyu, and to add a new (only half-related) commit. |
hodlinator
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Untested Code Review re-ACK fad0cf6
git range-diff master fa69fba fad0cf6 on shows #include changes and new fad0cf6 commit.
git show fad0cf6 shows use of std::equal overload with 3 iterators being replaced with the generally safer std::ranges::equal (not really an issue in this specific case as we are comparing pairs of the same type MessageStartChars = std::array<uint8_t, 4>).
stickies-v
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ACK fad0cf6
Even though not having span comparison operators can make things a bit more verbose, these changes are needed to start using std::span over our own implementation. This approach seems like the least invasive one (cleaning up wherever possible), and I can't see any behaviour change.
| std::vector<std::byte> expect(entry.span.size()); | ||
| InsecureRandomContext(entry.seed).fillrand(expect); | ||
| assert(entry.span == expect); | ||
| assert(std::ranges::equal(entry.span, expect)); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nit: missing #include <algorithm>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Leaving as-is for now to not invalidate review. I'll follow-up with iwyu on all files, I guess.
sedited
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ACK fad0cf6
The last commit seems a bit random, why change that function and not any of the other occurrences of std::equal?
Good point! I'll address this, if I have to re-touch. |
|
Is this rfm with three acks, or does it need more? |
std::spanremoved the comparison operators, so it makes sense to remove them for theSpan"backport" as well. Usingstd::ranges::equalalso has the benefit that someSpantemporary constructions can now be dropped.This is required to move from
Spantowardstd::span.