-
Notifications
You must be signed in to change notification settings - Fork 716
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
[Lint] Introduce lint-includes.sh script #2740
[Lint] Introduce lint-includes.sh script #2740
Conversation
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.
ACK 5df485e
Rather than including the implementation file into the test, which is bad practice.
Instead of throwing boost::lexical_cast<double>()
instead of boost::random::{mt19937,uniform_int_distribution}
linter to test for duplicate includes, including of `.cpp` files, and introductions/removals of Boost modules.
5df485e
to
ad5717d
Compare
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.
good ACK ad5717d
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.
utACK ad5717d and merging...
This brings in the
lint-includes.sh
shell script from upstream (first introduced in bitcoin#11878) to automatically check for duplicate includes and expanded in bitcoin#13301 and bitcoin#13385 to check for the inclusion of.cpp
files and the introduction of new boost includes, respectively.The check for enforcing bracket include syntax (bitcoin#13230) is also included, but currently disabled, as we have yet to systematically switch to that syntax preference.
Three other upstream PRs are backported here as they are directly related to the removal of some boost dependencies and are very straight forward:
NOTE: #2711 removes the dependency on
boost/tuple/tuple.hpp
, so it makes sense to merge that first. submitting this now so the general concept/functionality can be reviewed prior to that PR being merged