[SERVER-81059] everything now includes <boost/preprocessor/control/iif.hpp> Created: 13/Sep/23 Updated: 29/Oct/23 Resolved: 24/Sep/23 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | 7.2.0-rc0 |
| Type: | Improvement | Priority: | Minor - P4 |
| Reporter: | Billy Donahue | Assignee: | Billy Donahue |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||||||
| Assigned Teams: |
Server Development Platform
|
||||||||||||
| Backwards Compatibility: | Fully Compatible | ||||||||||||
| Sprint: | Service Arch 2023-10-02 | ||||||||||||
| Participants: | |||||||||||||
| Description |
|
An include for a rather obscure boost preprocessor header has been added by the IWYU sweep, to over 1500 c++ source files.
I don't really understand why IWYU would do this to a file like I think maybe one of the other headers needs something from the iif.hpp header and IWYU didn't resolve that dependency appropriately. |
| Comments |
| Comment by Githook User [ 23/Sep/23 ] |
|
Author: {'name': 'Billy Donahue', 'email': 'billy.donahue@mongodb.com', 'username': 'BillyDonahue'}Message: |
| Comment by Zack Winter [ 14/Sep/23 ] |
|
It looks like it's getting triggered by "invariant()" since it uses "BOOST_PP_OVERLOAD", which eventually expands to use BOOST_PP_IIF_0: https://github.com/10gen/mongo/blob/master/src/mongo/util/assert_util_core.h#L106 ``` Probably a bug in IWYU where it believes that assert_util_core.h is exporting BOOST_PP_IIF_0 and server_status_metric.h (among others) are calling it directly. I created https://github.com/10gen/mongo/pull/15633 to skip over it, but it's still pretty annoying since the way we're using iwyu seems to require us to create a comment in every file that ignores it. |
| Comment by Billy Donahue [ 13/Sep/23 ] |
|
The file defines macros beginning with BOOST_PP_IIF. But boost uses BOOST_PP_IIF extensively internally. I think we should just do a trivial "grep and destroy" to back this out. |