ci, iwyu: Fix warnings in src/util and treat them as errors#34448
ci, iwyu: Fix warnings in src/util and treat them as errors#34448hebasto wants to merge 3 commits intobitcoin:masterfrom
src/util and treat them as errors#34448Conversation
|
The following sections might be updated with supplementary metadata relevant to reviewers and maintainers. ReviewsSee the guideline for information on the review process. 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. |
In file included from /home/admin/actions-runner/_work/_temp/src/hash.h:16:
/home/admin/actions-runner/_work/_temp/src/uint256.h:150:17: error: no member named 'HexDigit' in the global namespace
150 | *p1 = ::HexDigit(str[--digits]);
| ^~~~~~~~
/home/admin/actions-runner/_work/_temp/src/uint256.h:152:38: error: no member named 'HexDigit' in the global namespace
152 | *p1 |= ((unsigned char)::HexDigit(str[--digits]) << 4);
| ^~~~~~~~
2 errors generated. |
|
🚧 At least one of the CI tasks failed. HintsTry to run the tests locally, according to the documentation. However, a CI failure may still
Leave a comment here, if you need help tracking down a confusing failure. |
|
Seems pretty odd that IWYU can be "passing" here, but nothing actually compiles. |
c51291c to
154a854
Compare
154a854 to
2298908
Compare
2298908 to
deca8eb
Compare
…ETE_FLAG` 516be10 wallet: Rename `RecordType::DELETE` to `RecordType::DELETE_FLAG` (Hennadii Stepanov) Pull request description: On Windows, the `winnt.h` header defines `DELETE` as a macro for a "Standard Access Right" bitmask (0x00010000L). This introduces a fragile dependency on header inclusion order: if Windows headers happen to be included before the `RecordType` enum definition, the preprocessor expands `DELETE` into a numeric literal, causing syntax errors. Rename the enumerator to `DELETE_FLAG` to remove this fragility and avoid the collision entirely. Split from #34448. ACKs for top commit: maflcko: re-lgtm ACK 516be10 achow101: ACK 516be10 Tree-SHA512: eba054b395e18c07efb2901b28f542b042b62d85e1a798eeff35f8431530cb667fa791c47c4125cecdb689213b458ba396715495415e9b83bb322509a9376222
deca8eb to
695facc
Compare
|
Rebased on top of merged #34454. |
695facc to
6d800fe
Compare
|
Rebased on top of merged #34460. |
d743c29 to
639cdba
Compare
|
Rebased. |
Looks like |
Fixed in #34551. |
|
The only conflicting PR has been merged, so now seems like a good time to get this reviewed. Friendly ping @sedited @maflcko @willcl-ark :) |
639cdba to
edbd916
Compare
f8d2f30 ci: Extend diff context for clang-format (Hennadii Stepanov) Pull request description: This PR ensures `clang-format` can properly restore empty lines between header groups that were previously stripped by `fix_includes.py`. Addresses [this](#34448 (comment)) comment. ACKs for top commit: maflcko: lgtm ACK f8d2f30 l0rinc: untested code review ACK f8d2f30 sedited: ACK f8d2f30 Tree-SHA512: 97e5450fc15e415134aa1e74ee415f947173978d999afbc0f204e1cdb2f68309b763c8a2ad819c4597147fc15540600aa8c99477db64e961ad428d8f45f3d384
edbd916 to
8cb1a63
Compare
|
Rebased. |
|
🚧 At least one of the CI tasks failed. HintsTry to run the tests locally, according to the documentation. However, a CI failure may still
Leave a comment here, if you need help tracking down a confusing failure. |
8cb1a63 to
76762de
Compare
On Windows, the `winerror.h` header defines `WAIT_TIMEOUT` as a macro. This introduces a fragile dependency on header inclusion order: if Windows headers happen to be included before using `WAIT_TIMEOUT`, the preprocessor expands it into a numeric literal, causing syntax errors. Rename the variable to `TEST_WAIT_TIMEOUT` to remove this fragility and avoid the collision entirely.
76762de to
adcaac7
Compare
| @@ -8,6 +8,7 @@ | |||
|
|
|||
| #include <crypto/siphash.h> | |||
| #include <logging/categories.h> // IWYU pragma: export | |||
There was a problem hiding this comment.
If this PR is going to fix util, then I think pretty much any (existing) pramga use, outside of the config header, should be getting comments (especially given the prior added one was another IWYU bug). Pragmas should be used sparingly, and explained when so.
There was a problem hiding this comment.
I agree that all pragmas should eventually be documented. However, addressing the existing ones here would significantly expand the scope of this PR and likely introduce more merge conflicts.
Since these older pragmas might need to be removed entirely rather than just documented, it would be best to loop in the original authors or reviewers to make that call. I think it makes the most sense to tackle this cleanup in follow-up PRs.
There was a problem hiding this comment.
However, addressing the existing ones here would significantly expand the scope of this PR
Looking at the current state of this PR, there are 4 instances of // IWYU pragma: export in src/util/. Documenting or removing them, seems in scope for a PR that is fixing all issues in src/util/. If not done now, we'll just have to come back again later and fix them anyways (and still have merge conflicts anyways, if there are any).
Since these older pragmas might need to be removed entirely rather than just documented,
it would be best to loop in the original authors or reviewers to make that call.
Isn't the best case if you can just delete the pragma, and fix the includes? Otherwise I'm not sure what call they would need to make. Either the pragma is removed, and includes fixed, there is a IWYU bug (which can be documented), or a rationale is written for keeping the pragma (even if it isn't needed)?
|
Drafted. Please review #34639 first. |
This PR continues the ongoing effort to enforce IWYU warnings.
See Developer Notes.