Skip to content

Conversation

@hebasto
Copy link
Member

@hebasto hebasto commented Oct 28, 2025

This PR continues the work from #31308 by extending the treatment of IWYU warnings as errors to the src/init and src/policy directories.

@DrahtBot
Copy link
Contributor

DrahtBot commented Oct 28, 2025

The following sections might be updated with supplementary metadata relevant to reviewers and maintainers.

Code Coverage & Benchmarks

For details see: https://corecheck.dev/bitcoin/bitcoin/pulls/33725.

Reviews

See the guideline for information on the review process.

Type Reviewers
Stale ACK maflcko

If your review is incorrectly listed, please react with 👎 to this comment and the bot will ignore it on the next update.

Conflicts

Reviewers, this pull request conflicts with the following ones:

  • #33892 (policy: Remove individual transaction <minrelay restriction by instagibbs)
  • #33779 (ci, iwyu: Fix warnings in src/kernel and treat them as errors by hebasto)
  • #33629 (Cluster mempool by sdaftuar)
  • #33199 (fees: enable CBlockPolicyEstimator return sub 1 sat/vb fee rate estimates by ismaelsadeeq)
  • #32545 (Replace cluster linearization algorithm with SFL by sipa)
  • #31664 (Fees: add Fee rate Forecaster Manager by ismaelsadeeq)
  • #30157 (Fee Estimation via Fee rate Forecasters by ismaelsadeeq)
  • #29060 (Policy: Report debug message why inputs are non standard by ismaelsadeeq)

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.

@hebasto
Copy link
Member Author

hebasto commented Oct 28, 2025

Friendly ping @l0rinc @maflcko @ryanofsky @willcl-ark who reviewed #31308.

This was referenced Oct 28, 2025
Copy link
Member

@maflcko maflcko left a 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==


#include <algorithm>
#include <cstddef>
#include <span>
Copy link
Member

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.

Copy link
Member Author

@hebasto hebasto Oct 28, 2025

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.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks! Reworked.

Copy link
Contributor

@purpleKarrot purpleKarrot Oct 29, 2025

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.

Copy link
Member

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:

#include <chrono> // IWYU pragma: export

Also for the validation.h include:

#include <kernel/cs_main.h> // IWYU pragma: export
. There, the harm could be larger, as the validation header is a bit larger than the cs_main header, but it feels a bit verbose to redundantly include cs_main where validation is included.

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`.
@fanquake
Copy link
Member

this pull request conflicts with the following ones:
#33629 (Cluster mempool by sdaftuar)
#33591 (Cluster mempool followups by sdaftuar)

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 v31. Could instead do directories that rarely change, like qt, or zmq?

-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 \
Copy link
Member

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?

Copy link
Member Author

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.

@hebasto
Copy link
Member Author

hebasto commented Oct 29, 2025

this pull request conflicts with the following ones:
#33629 (Cluster mempool by sdaftuar)
#33591 (Cluster mempool followups by sdaftuar)

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 v31.

I agree, and when I noticed these conflicts, I checked that those PRs don't have any ACKs yet.

Could instead do directories that rarely change, like qt, or zmq?

Right.

@maflcko
Copy link
Member

maflcko commented Oct 30, 2025

Other candidates could be: common/ compat/ primitives/ script/ support/ util/ zmq/

@DrahtBot
Copy link
Contributor

🐙 This pull request conflicts with the target branch and needs rebase.

@hebasto hebasto closed this Dec 22, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants