9446de160f
9b0a13a2891641a3d12e525cee8ddddb1aa1bc73 tidy: Add include-what-you-use (fanquake) 74cd038e300bfbe2473295fc3b0c3a4f3e853a07 refactor: fix includes in src/init (fanquake) c79ad935f0412bac3e19a6b925efdb390eb00bd9 refactor: fix includes in src/compat (fanquake) Pull request description: We recently added a [`clang-tidy` job](https://github.com/bitcoin/bitcoin/blob/master/ci/test/00_setup_env_native_tidy.sh) to the CI, which generates a compilation database. We can leverage that now existing database to begin running [include-what-you-use](https://include-what-you-use.org/) over the codebase. This PR demonstrates using a mapping_file to indicate fixups / includes that may differ from IWYU suggestions. In this case, I've added some fixups for glibc includes that I've [upstreamed changes for](https://github.com/include-what-you-use/include-what-you-use/pull/1026): ```bash # Fixups / upstreamed changes [ { include: [ "<bits/termios-c_lflag.h>", private, "<termios.h>", public ] }, { include: [ "<bits/termios-struct.h>", private, "<termios.h>", public ] }, { include: [ "<bits/termios-tcflow.h>", private, "<termios.h>", public ] }, ] ``` The include "fixing" commits of this PR: * Adds missing includes. * Swaps C headers for their C++ counterparts. * Removes the pointless / unmaintainable `//for abc, xyz` comments. When using IWYU, if anyone wants to see / generate those comments, to see why something is included, it is trivial to do so (IWYU outputs them by default). i.e: ```cpp // The full include-list for compat/stdin.cpp: #include <compat/stdin.h> #include <poll.h> // for poll, pollfd, POLLIN #include <termios.h> // for tcgetattr, tcsetattr #include <unistd.h> // for isatty, STDIN_FILENO ``` TODO: - [ ] Qt mapping_file. There is one in the IWYU repo, but it's for Qt 5.11. Needs testing. - [ ] Boost mapping_file. There is one in the IWYU repo, but it's for Boost 1.75. Needs testing. I'm not suggesting we turn this on the for entire codebase, or immediately go-nuts refactoring all includes. However I think our dependency includes are now slim enough, and our CI infrastructure in place such that we can start doing this in some capacity, and just automate away include fixups / refactorings etc. ACKs for top commit: MarcoFalke: review ACK 9b0a13a2891641a3d12e525cee8ddddb1aa1bc73 jonatack: ACK 9b0a13a2891641a3d12e525cee8ddddb1aa1bc73 reviewed changes and run CI output in https://cirrus-ci.com/task/4750910332076032 Tree-SHA512: 00beab5a5f2a6fc179abf08321a15391ecccaa91ab56f3c50c511e7b29a0d7c95d8bb43eac2c31489711086f6f77319d43d803cf8ea458e7cd234a780d9ae69e
Repository Tools
Developer tools
Specific tools for developers working on this repository.
Additional tools, including the github-merge.py script, are available in the maintainer-tools repository.
Verify-Commits
Tool to verify that every merge commit was signed by a developer using the github-merge.py script.
Linearize
Construct a linear, no-fork, best version of the blockchain.
Qos
A Linux bash script that will set up traffic control (tc) to limit the outgoing bandwidth for connections to the Bitcoin network. This means one can have an always-on bitcoind instance running, and another local bitcoind/bitcoin-qt instance which connects to this node and receives blocks from it.
Seeds
Utility to generate the pnSeed[] array that is compiled into the client.
Build Tools and Keys
Packaging
The Debian subfolder contains the copyright file.
All other packaging related files can be found in the bitcoin-core/packaging repository.
Builder keys
PGP keys used for signing Bitcoin Core release results.
MacDeploy
Scripts and notes for Mac builds.
Test and Verify Tools
TestGen
Utilities to generate test vectors for the data-driven Bitcoin tests.
Verify Binaries
This script attempts to download and verify the signature file SHA256SUMS.asc from bitcoin.org.