-
Notifications
You must be signed in to change notification settings - Fork 36.7k
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
refactor: Remove Span operator==, Use std::ranges::equal #29071
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. |
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 fabcd0c
fabcd0c
to
fa69fba
Compare
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 fa69fba
git range-diff master fabcd0c fa69fba
reveals pure whitespace change.
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. |
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>
).
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.
@@ -78,7 +78,7 @@ class PoolResourceFuzzer | |||
{ | |||
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.
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::span
removed the comparison operators, so it makes sense to remove them for theSpan
"backport" as well. Usingstd::ranges::equal
also has the benefit that someSpan
temporary constructions can now be dropped.This is required to move from
Span
towardstd::span
.