This PR:
Updates to IWYU 0.25, which is compatible with Clang 21.
Fixes new "modernize-use-default-member-init" warnings. The warning in
interpreter.cppis a false positive, so it has been suppressed.
This PR:
Updates to IWYU 0.25, which is compatible with Clang 21.
Fixes new "modernize-use-default-member-init" warnings. The warning in interpreter.cpp is a false positive, so it has been suppressed.
<!--e57a25ab6845829454e8d69fc972939a-->
The following sections might be updated with supplementary metadata relevant to reviewers and maintainers.
<!--006a51241073e994b41acfe9ec718e94-->
For details see: https://corecheck.dev/bitcoin/bitcoin/pulls/33445.
<!--021abf342d371248e50ceaed478a90ca-->
See 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.
<!--5faf32d7da4f0f540f40219e4f7537a3-->
Could you please take a look at the following IPC-related warning:
/usr/include/kj/async-inl.h:404:12: warning: Out of bound access to memory preceding the region [clang-analyzer-security.ArrayBound]
404 | ctor(*ptr, kj::mv(next), kj::fwd<Params>(params)...);
| ^
17 | @@ -18,10 +18,10 @@ class WalletModel; 18 | class RecentRequestEntry 19 | { 20 | public: 21 | - RecentRequestEntry() : nVersion(RecentRequestEntry::CURRENT_VERSION) {} 22 | + RecentRequestEntry() = default;
Correct me if I am wrong, in the absence of other constructors (like in RecentRequestEntry), this line is not needed because it will generate the same constructor that will be generated if we don't specify any constructor. In other words, I suggest to drop the line RecentRequestEntry() = default;.
Your analysis seems correct to me. However, I prefer being explicit here. Otherwise, if any user-declared constructor is added in the future, the default constructor would not be generated.
12 | @@ -13,8 +13,7 @@ 13 | 14 | TransactionFilterProxy::TransactionFilterProxy(QObject* parent) 15 | : QSortFilterProxyModel(parent), 16 | - m_search_string(), 17 | - typeFilter(ALL_TYPES) 18 | + m_search_string()
My understanding is that such default constructing is not needed because m_search_string will be default constructed anyway. That is, drop the line m_search_string().
20 | @@ -21,7 +21,7 @@ class CZMQAbstractNotifier 21 | public: 22 | static const int DEFAULT_ZMQ_SNDHWM {1000}; 23 | 24 | - CZMQAbstractNotifier() : outbound_message_high_water_mark(DEFAULT_ZMQ_SNDHWM) {} 25 | + CZMQAbstractNotifier() = default;
Same here, remove CZMQAbstractNotifier() = default;?
ACK ecacfac7ead178ace3b0ec9393a7c63b5d8d3576
ACK 1bb0f7f8b6d927046fefa2eb29d0132713415cca
1252 | @@ -1253,8 +1253,10 @@ class CTransactionSignatureSerializer 1253 | const CScript& scriptCode; //!< output script being consumed 1254 | const unsigned int nIn; //!< input index of txTo being signed 1255 | const bool fAnyoneCanPay; //!< whether the hashtype has the SIGHASH_ANYONECANPAY flag set 1256 | + // NOLINTBEGIN(modernize-use-default-member-init) 1257 | const bool fHashSingle; //!< whether the hashtype is SIGHASH_SINGLE 1258 | const bool fHashNone; //!< whether the hashtype is SIGHASH_NONE 1259 | + // NOLINTEND(modernize-use-default-member-init)
In commit "ci: Update Clang in "tidy" job" (1bb0f7f8b6d927046fefa2eb29d0132713415cca)
I'm confused about why these are necessary. What makes these two members different from the fAnyoneCanPay member and causes clang-tidy to warn about them but not fAnyoneCanPay? All three members seem to be set in the same way by the same nHashTypeIn constructor argument.
This seems more like a bug that should be reported upstream than a change that should be made to our code. And if the change is necessary it would seem good to have a comment saying it is a temporary workaround.
This seems more like a bug that should be reported upstream...
... it would seem good to have a comment saying it is a temporary workaround.
Thanks! Done.
Code review ACK 1bb0f7f8b6d927046fefa2eb29d0132713415cca. Nice code cleanups, though did leave one comment about the NOLINT.
re: #33445 (comment)
Could you please take a look at the following IPC-related warning:
Thanks, created https://github.com/capnproto/capnproto/pull/2417 to address it
re: #33445 (comment)
Could you please take a look at the following IPC-related warning:
Thanks, created capnproto/capnproto#2417 to address it
I've added a commit to temporarily silence this warning.
The feedback from @ryanofsky has been addressed.
ACK 5b20d172ca2a46a2b525201b4ff2444f9d415d8c
176 | @@ -177,6 +177,8 @@ if(ENABLE_IPC) 177 | ipc_tests.cpp 178 | ) 179 | target_link_libraries(test_bitcoin bitcoin_ipc_test bitcoin_ipc) 180 | + 181 | + configure_file(.clang-tidy.in .clang-tidy USE_SOURCE_PERMISSIONS COPYONLY)
In commit "clang-tidy: Disable ArrayBound check in src/ipc and src/test" (5b20d172ca2a46a2b525201b4ff2444f9d415d8c)
Kind of a shame to need this outside of the IPC directory. Maybe there should be a src/ipc/test subdirectory like src/wallet/test to keep IPC stuff grouped together.
The same thought occurred to me while working on this PR, but I thought it might be better to defer it to a separate PR. Do you think itβs worth adding another commit to move the tests here?
re: #33445 (review)
The same thought occurred to me while working on this PR, but I thought it might be better to defer it to a separate PR. Do you think itβs worth adding another commit to move the tests here?
I was thinking of it as a followup for a future PR, but I'm actually not sure how big the change would be and whether it might require code changes. Maybe if it's a small change it would be easy to make here. Whatever your preference is seems fine and I do think current solution makes sense given the current layout.
I was thinking of it as a followup for a future PR...
I agree with that.
... but I'm actually not sure how big the change would be and whether it might require code changes.
Something like a978c6bdb41fd3f8461908c30bb409a26fa62d47 in https://github.com/hebasto/bitcoin/commits/250925-llvm-tidy/.
Code review ACK 5b20d172ca2a46a2b525201b4ff2444f9d415d8c. Just added link to upstream modernize-use-default-member-init bug (thanks for looking into that and reporting) and added new suppressions for capnproto clang-tidy errors since last review
This change updates to IWYU 0.25, which is compatible with Clang 21.
Fixes new "modernize-use-default-member-init" warnings.
The warning in `interpreter.cpp` is a false positive, so it has been
suppressed.
1252 | @@ -1254,8 +1253,12 @@ class CTransactionSignatureSerializer 1253 | const CScript& scriptCode; //!< output script being consumed 1254 | const unsigned int nIn; //!< input index of txTo being signed 1255 | const bool fAnyoneCanPay; //!< whether the hashtype has the SIGHASH_ANYONECANPAY flag set 1256 | + // Temporary workaround for a clang-tidy bug.
Given the upstream fix has landed (and was possibly backported?), this workaround should either be removed entirely, or updated to indicate the version of Clang which this was fixed in.
The comment has been updated.
and was possibly backported?
No, it wasn't.
Code review ACK 5d784bebaff5e3acc0b5180ee51d9a16aec0e356, just adding clang version comment since last review.
Would still be nice to remove ipc build code from the test directory as a followup too (https://github.com/bitcoin/bitcoin/pull/33445#discussion_r2379651340)
review ACK 5d784bebaff5e3acc0b5180ee51d9a16aec0e356 π
<details><summary>Show signature</summary>
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 5d784bebaff5e3acc0b5180ee51d9a16aec0e356 π
/Flat3dfMtdVCyisqRmXnrrqdQxlTYjyYTH6+6P04ON5gkskBepJWaDELcnfysyR58QGN+HTU8o8hccPj1YtDg==
</details>