False positive in Boos.Test

[correaa]

I have a library that has tests that heavily rely on Boost.Test.

I usually get lots of errors such as below, and the "rules" included in --mapping_file=/usr/share/include-what-you-use/boost-all.imp don't help at all.

/home/user/boost-multi/include/boost/multi/adaptors/fftw/test/combinations.cpp should add these lines:
#include <bits/chrono.h>                                // for operator-
#include <boost/preprocessor/comparison/not_equal.hpp>  // for BOOST_PP_NOT_...
#include <boost/preprocessor/control/iif.hpp>           // for BOOST_PP_IIF_1
#include <boost/preprocessor/logical/bool.hpp>          // for BOOST_PP_BOOL_2
#include <boost/preprocessor/logical/compl.hpp>         // for BOOST_PP_COMPL_1
#include <boost/test/framework.hpp>                     // for current_test_...
#include <boost/test/tools/old/interface.hpp>           // for BOOST_REQUIRE
#include <boost/test/tree/decorator.hpp>                // for base, enabled
#include <boost/test/tree/test_unit.hpp>                // for test_case
#include <boost/test/unit_test_suite.hpp>               // for BOOST_AUTO_TE...
#include <boost/test/utils/lazy_ostream.hpp>            // for operator<<

/home/correaa/boost-multi/include/boost/multi/adaptors/fftw/test/combinations.cpp should remove these lines:
- #include <boost/test/unit_test.hpp>  // lines 6-6
- #include <chrono>  // lines 14-14

The full include-list for /home/correaa/boost-multi/include/boost/multi/adaptors/fftw/test/combinations.cpp:
#include <bits/chrono.h>                                // for operator-
#include <algorithm>                                    // for generate, for...
#include <array>                                        // for array
#include <boost/multi/adaptors/fftw.hpp>                // for dft, forward
#include <boost/multi/array.hpp>                        // for array, operat...
#include <boost/preprocessor/comparison/not_equal.hpp>  // for BOOST_PP_NOT_...
#include <boost/preprocessor/control/iif.hpp>           // for BOOST_PP_IIF_1
#include <boost/preprocessor/logical/bool.hpp>          // for BOOST_PP_BOOL_2
#include <boost/preprocessor/logical/compl.hpp>         // for BOOST_PP_COMPL_1
#include <boost/test/framework.hpp>                     // for current_test_...
#include <boost/test/tools/fpc_tolerance.hpp>           // for tolerance
#include <boost/test/tools/old/interface.hpp>           // for BOOST_REQUIRE
#include <boost/test/tree/decorator.hpp>                // for base, enabled
#include <boost/test/tree/test_unit.hpp>                // for test_case
#include <boost/test/unit_test_suite.hpp>               // for BOOST_AUTO_TE...
#include <boost/test/utils/lazy_ostream.hpp>            // for operator<<
#include <complex>                                      // for complex, oper...
#include <iostream>                                     // for operator<<
#include <numeric>                                      // for iota
#include <random>                                       // for linear_congru...
#include <string>                                       // for operator""s
#include <utility>                                      // for move
#include <vector>                                       // for vector

I found that adding this mapping file solves all the problems, some are perhaps could be included in the test itself, but others are really implementation details.

I am using this mapping file. Would it make sense to propose its inclusion in the official boost-all.imp?

[
    { "include": ["@<boost/preprocessor/comparison/not_equal.hpp>", "private", "<boost/test/unit_test.hpp>", "public"] },
    { "include": ["@<boost/preprocessor/control/iif.hpp>", "private", "<boost/test/unit_test.hpp>", "public"] },
    { "include": ["@<boost/preprocessor/logical/bool.hpp>", "private", "<boost/test/unit_test.hpp>", "public"] },
    { "include": ["@<boost/preprocessor/logical/compl.hpp>", "private", "<boost/test/unit_test.hpp>", "public"] },
    { "include": ["@<boost/test/tools/assertion.hpp>", "private", "<boost/test/unit_test.hpp>", "public"] },
    { "include": ["@<boost/test/tools/interface.hpp>", "private", "<boost/test/unit_test.hpp>", "public"] },
    { "include": ["@<boost/test/tools/old/interface.hpp>", "private", "<boost/test/unit_test.hpp>", "public"] },
    { "include": ["@<boost/test/tools/old/interface.hpp>", "private", "<boost/test/unit_test.hpp>", "public"] },
    { "include": ["@<boost/test/tools/old/interface.hpp>", "private", "<boost/test/unit_test.hpp>", "public"] },
    { "include": ["@<boost/test/tree/decorator.hpp>", "private", "<boost/test/unit_test.hpp>", "public"] },
    { "include": ["@<boost/test/tree/test_unit.hpp>", "private", "<boost/test/unit_test.hpp>", "public"] },
    { "include": ["@<boost/test/unit_test_suite.hpp>", "private", "<boost/test/unit_test.hpp>", "public"] },
    { "include" :["@<boost/test/framework.hpp>", "public", "<boost/test/unit_test.hpp>", "public"] },
    { "include": ["@<boost/test/unit_test_log.hpp>", "public", "<boost/test/unit_test.hpp>", "public"] },
    { "include": ["@<boost/test/utils/lazy_ostream.hpp>", "public", "<boost/test/unit_test.hpp>", "public"] },
    { "include": ["@<boost/test/utils/wrap_stringstream.hpp>", "public", "<boost/test/unit_test.hpp>", "public"] },
]

I had to make some "includes" public because otherwise they would conflict with the boost-all mapping file, in case both imp files are necessary.

[kimgr]

I'm a bit reluctant to make hand-edited changes to these mappings, I've been meaning to create a mapping generator for Boost for a while, a la: https://github.com/include-what-you-use/include-what-you-use/tree/master/mapgen.

The goal is to make it easy enough for users to generate mappings from their actual local install tree, rather than us having to try and maintain version-agnostic master mappings for all public liibraries. A longer-term goal is to make it possible for libraries to ship with mappings, so library authors can provide hints, but there's a bunch of small roadblocks in the way: #1271

[correaa]

I see.

In the case of Boost, at least, it is not just a matter of making it work from a local tree.
Because one might want the library to compile with different versions of Boost.
For example, in a CI machine, where one doesn't have easy access or immediate access to the tree.

Unless you are planning to remove boost-all.imp, I still suggest the change.

[firewave]

This is essentially an duplicate of #1046 and #227. I will elaborate on it in the latter.

[kimgr]

@firewave Thanks, let's keep all Boost mapping discussions centered in #227. Closing as duplicate.