-
Notifications
You must be signed in to change notification settings - Fork 38.6k
ci, iwyu: Treat warnings as errors for src/init and src/policy
#33725
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 Coverage & BenchmarksFor details see: https://corecheck.dev/bitcoin/bitcoin/pulls/33725. 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. |
|
Friendly ping @l0rinc @maflcko @ryanofsky @willcl-ark who reviewed #31308. |
30e5b01 to
a36b932
Compare
a36b932 to
8ae41ae
Compare
maflcko
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.
review ACK 8ae41ae 🐇
Show signature
Signature:
untrusted comment: signature from minisign secret key on empty file; verify via: minisign -Vm "${path_to_any_empty_file}" -P RWTRmVTMeKV5noAMqVlsMugDDCyyTSbA3Re5AkUrhvLVln0tSaFWglOw -x "${path_to_this_whole_four_line_signature_blob}"
RUTRmVTMeKV5npGrKx1nqXCw5zeVHdtdYURB/KlyA/LMFgpNCs+SkW9a8N95d+U4AP1RJMi+krxU1A3Yux4bpwZNLvVBKy0wLgM=
trusted comment: review ACK 8ae41ae6f2c2ccc129a84f8f2cc8ae415e2125e0 🐇
/yGQlCLoD+y92eefuzREel2J883stbBwa/+Pt1X3bzg5mC8jGDGvjG7pgVwg7TuvT7ZyPcl1EZc2Tk7H1ZdqDg==
src/policy/policy.cpp
Outdated
|
|
||
| #include <algorithm> | ||
| #include <cstddef> | ||
| #include <span> |
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 in 8ae41ae: Same here: Doesn't matter much, but the benefit of including span, when span.h is included, seems limited.
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.
Right. But let me leave this change for a follow-up, as it would touch files in src/crypto.
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.
Thanks! Reworked.
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.
but the benefit of including span, when span.h is included, seems limited.
That is not the right rationale. Since span.h may get phased out by future refactoring, it is advantageous to have an indicator at the top of the file whether <span> is used purely directly or directly and indirectly.
To give a more concrete example: If I refactor a piece of code such that no code from span.h is used anymore, I want iwyu to tell me that the #include <span.h> directive can be removed. When that file exports symbols from <span>, it will depend on the include order whether iwyu will suggest the removal or not.
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.
Yeah, I can see it both ways. I think the possible harm from including span.h over span is limited with this trivial header. Just noting I did the same with the time.h include:
Line 9 in 3bb3065
| #include <chrono> // IWYU pragma: export |
Also for the validation.h include:
Line 19 in 3bb3065
| #include <kernel/cs_main.h> // IWYU pragma: export |
Though, no strong opinion. This is just my thinking and anything is fine here, as long as reviewers are happy with it.
Headers that are no longer available via transitive includes are now included directly in `bitcoin-tx.cpp` and sources in `src/test`.
8ae41ae to
35f8874
Compare
I think if you want to continue these refactors, it might be better if you picked code that doesn't conflict with Cluster Mempool or Kernel work, or things we are trying to ship in |
| -p "${BASE_BUILD_DIR}" "${MAKEJOBS}" -- \ | ||
| -Xiwyu --cxx17ns \ | ||
| -Xiwyu --mapping_file="${BASE_ROOT_DIR}/contrib/devtools/iwyu/bitcoin.core.imp" \ | ||
| -Xiwyu --mapping_file=/include-what-you-use/boost-1.75-all.imp \ |
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.
include-what-you-use/boost-1.75-all.imp
I guess this is still correct-enough to use here, but are we making any effort to usptream updates, given it's 14 Boost releases out of date (current release is 1.89.0)? Seems possible that this could lead to incorrect IWYU suggestions, given any recent Boost refactorings?
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.
We use a tiny part of Boost, which seems quite stable. So I don’t think it’s worth the effort.
I agree, and when I noticed these conflicts, I checked that those PRs don't have any ACKs yet.
Right. |
|
Other candidates could be: |
|
🐙 This pull request conflicts with the target branch and needs rebase. |
This PR continues the work from #31308 by extending the treatment of IWYU warnings as errors to the
src/initandsrc/policydirectories.