Pull request 882 in include-what-you-use: Add Boost 1.75.0 mappings
notifi...@include-what-you-use.org
https://github.com/include-what-you-use/include-what-you-use/pull/882
Based on the original notes on `boost-1.64-all.imp` and `boost-1.64-all-private.imp`, here's the latest version.
Please check my comments on the first lines of `boost-1.75-all-private.imp`.
Notes:
- I modified the commands used for generation, and manual steps are also added. Those are written in the comments.
- Added boost/regex/v4 handling.
- Added boost/lexical_cast handling.
- Added Boost.Geometry uncommon header handling (you really should check my comments on `boost-1.75-all-private.imp`)
- Mark MPL includes as 'private' in libraries except for MPL itself, to suppress redundant suggestions (unfortunately some libraries #include MPL headers in public API, so that it leads to IWYU suggestion on the application side)
notifi...@include-what-you-use.org
https://github.com/include-what-you-use/include-what-you-use/pull/882
Nice! I'm working on a Python script to generate boost mappings automatically. I wonder if that could/should adopt some of your manual fixups.
I'm a little pressed for time to work on that right now, so maybe we should keep with manually edited mappings for now.
notifi...@include-what-you-use.org
https://github.com/include-what-you-use/include-what-you-use/pull/882
AFAIU, the recursive (cycle) resolution bug #424 will cause headaches for auto mapping because
- Boost.Preprocessor focuses on (or more precisely, abuses) that technique to generate sources
- See: https://github.com/include-what-you-use/include-what-you-use/issues/424#issuecomment-758553633
- My `boost-1.75-all-private.imp` avoids this issue by simply removing Boost.PP's recursive headers
- More trivial cases (such as https://github.com/include-what-you-use/include-what-you-use/issues/424#issue-219721065) might potentially exist in more places other than those we've already found
If we are to implement current 'workarounds' noted in boost-*-.imp, I think it results in same maintenance cost. The difference is just doing it manually, or doing it in IWYU's side. If Boost's header structure changes, then we need to update mapping generation mechanism anyway.
For Boost, it should be fine to require human steps to create new mapping config. The release schedule is based on few months span, so the maintenance cost should be bearable. However I admit that I am generally happy about implementing some dirty work in scripts to avoid human steps, so I'm not opposing to building some nice Python script.
You can merge this PR if the proposed mapping files don't contain mistakes.
notifi...@include-what-you-use.org
https://github.com/include-what-you-use/include-what-you-use/pull/882
I don't use Boost myself and we don't have a test harness for mappings in general. The changes look good to me, so if you have tested this with a code base using Boost, I think we can merge it as-is.
notifi...@include-what-you-use.org
https://github.com/include-what-you-use/include-what-you-use/pull/882
I'm using this mapping in my own codebase, which is a GIS middleware written in C++20 (30000+ lines of code) using Boost 1.75.0 (especially Boost.Geometry) and Clang 13. I've been running iwyu with this mapping for at least 10 days, seeing no issues. I will kindly accept any future fixes related to the mapping mistake, but shall we merge this for now?
notifi...@include-what-you-use.org
https://github.com/include-what-you-use/include-what-you-use/pull/882
@saki7 Thanks, that's the kind of confirmation I needed to hear :). Sounds good, let's merge :tada: