This PR reduces false warnings, especially for unit tests.
From the Boost.Test’s point of view, the boost/test/unit_test.hpp
header:
0... should be the only header necessary to include to start using the framework
This PR reduces false warnings, especially for unit tests.
From the Boost.Test’s point of view, the boost/test/unit_test.hpp
header:
0... should be the only header necessary to include to start using the framework
The following sections might be updated with supplementary metadata relevant to reviewers and maintainers.
For detailed information about the code coverage, see the test coverage report.
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.
No conflicts as of last run.
24+ { include: [ "<boost/test/tools/old/interface.hpp>", public, "<boost/test/unit_test.hpp>", public ] },
25+ { include: [ "<boost/test/tree/test_unit.hpp>", public, "<boost/test/included/unit_test.hpp>", public ] },
26+ { include: [ "<boost/test/unit_test_log.hpp>", public, "<boost/test/unit_test.hpp>", public ] },
27+ { include: [ "<boost/test/unit_test_suite.hpp>", public, "<boost/test/unit_test.hpp>", public ] },
28+ { include: [ "<boost/test/utils/basic_cstring/basic_cstring.hpp>", public, "<boost/test/unit_test.hpp>", public ] },
29+ { include: [ "<boost/test/utils/lazy_ostream.hpp>", public, "<boost/test/unit_test.hpp>", public ] },
boost-1.75-all.imp
and qt5_11.imp
, given they are clearly for older versions. Are we going to upstream updates, or just wait until the mappings break?
contrib/devtools/iwyu/bitcoin.core.imp
isn’t modified by anyone else, so shouldn’t cause any (silent) merge conflicts?
If you want to look for missing ones, there should be at least signals2? See api.cirrus-ci.com/v1/task/4955079116062720/logs/ci.log with search string “+#include <boos”
Thanks! Done.
contrib/devtools/iwyu/bitcoin.core.imp
isn’t modified by anyone else, so shouldn’t cause any (silent) merge conflicts?
You’re right. I meant actually adding/removing boost/signals2/*
headers in the code.
#include <boost/multi_index/hashed_index.hpp> // for hashed_index_iterator
etc … ?
Same for
#include <boost/multi_index/hashed_index.hpp> // for hashed_index_iterator
etc … ?
Are you still working on this?
Same for
#include <boost/multi_index/hashed_index.hpp> // for hashed_index_iterator
etc … ?
Why? boost/multi_index/hashed_index.hpp
is a public header. And all IWYU’s suggestions about it look correct.
Or did I miss something?
IWYU
export
ed from the header that exports the boost include.
IWYU
export
the boost include, because it is an implementation detail limited to this single module. Modules including this module shouldn’t be bothered with implementation details of it.
28+ { include: [ "<boost/test/utils/basic_cstring/basic_cstring.hpp>", public, "<boost/test/unit_test.hpp>", public ] },
29+ { include: [ "<boost/test/utils/lazy_ostream.hpp>", public, "<boost/test/unit_test.hpp>", public ] },
30+
31+ # Boost.Signals2
32+ { symbol: ["boost::function", "private", "<boost/signals2/signal.hpp>", "public" ] },
33+ { symbol: ["boost::optional", "private", "<boost/signals2/optional_last_value.hpp>", "public" ] },
Seems an implementation detail of boost/signal that should map to boost/signals2/signal.hpp
?
Edit: NVM. This is a public class. https://www.boost.org/doc/libs/1_82_0/doc/html/boost/signals2/optional_last_value.html
boost/signals2/signal.hpp
and boost/signals2/optional_last_value.hpp
headers, I’d say that the boost/optional.hpp
header is an implementation details of the latter, not former.
Forget my earlier comments. I think this is correct, or at least a good step in the right direction.
lgtm ACK b2634ad1ed884ff7cd32f00cb45075c100902763
Forget my earlier comments.
Including #27710 (review)?
0@@ -1,7 +1,33 @@
1 # Fixups / upstreamed changes
2 [
3- { include: [ "<bits/termios-c_lflag.h>", private, "<termios.h>", public ] },
4- { include: [ "<bits/termios-struct.h>", private, "<termios.h>", public ] },
5- { include: [ "<bits/termios-tcflow.h>", private, "<termios.h>", public ] },
6 { include: [ "<bits/chrono.h>", private, "<chrono>", public ] },
7+
8+ # Boost.Test
What’s the reason for leaving certain mappings out of this list, i.e #include <boost/operators.hpp>
?
I’m guessing it’s because those same includes are recommended for non-test code, and mapping them to Boost Test here would just produce nonsense recommendations for other files? If so, how are you planning on working around that in future? If not, or that isn’t a problem, why not do the mapping now?
What’s the reason for leaving certain mappings out of this list, i.e
#include <boost/operators.hpp>
?
To keep this PR in reviewable state. For example, a bunch of public Boost headers must be included explicitly and added to a linter:
boost/multi_index/identity.hpp
boost/multi_index/indexed_by.hpp
boost/multi_index/tag.hpp
boost/tuple/tuple.hpp
UPD: see #27783
I’m guessing it’s because those same includes are recommended for non-test code, and mapping them to Boost Test here would just produce nonsense recommendations for other files? If so, how are you planning on working around that in future? If not, or that isn’t a problem, why not do the mapping now?
That’s not a problem, at all. The PR has been updated.
Addressed @fanquake’s #27710 (review).
I don’t see how this is addressed, looks like it’s now just producing include suggestions that are incorrect/we don’t want for the test code.
… looks like it’s now just producing include suggestions that are incorrect/we don’t want for the test code.
Can you point out these suggestions please? Asking because I’ve just skimmed suggestions for test/*_tests.cpp
files again and I can see none of them in comparison to the master branch.
Needs rebase for fresh CI?
Done.
are you still working on this?
I don’t think I will work on this PR in the nearest future.