Fix #include inside boost namespace

[dscharrer]

The existing code fails to build if was not already included.

[jwakely]

This needs to be fixed in a 1.76.1 release because it's currently totally broken with GCC trunk. I've refactored some libstdc++ headers so that the whole of <utility> is included less often by other headers in the library. Now it doesn't get implicitly included before reaching this bug, and so the first time it gets included is in the wrong namespace.

[jwakely]

The #include inside the boost::math namespace is obviously totally broken, but so is testing the __cpp_lib_integer_sequence feature test macro before including <utility>. Unless you include <version> (which isn't present on older implementations) then the only guaranteed way to get the macro is by including <utility>. So using it as the condition to decide whether or not to include <utility> is backwards.

You could do:

#ifdef __has_include
# if __has_include(<version>)
#  include <version>
#  define BOOST_MATH_HAVE_VERSION_HDR 1
#endif 
#endif 

#ifdef BOOST_MATH_HAVE_VERSION_HDR
# include <version>
#else
# include <utility>
#endif

....

#ifdef __cpp_lib_integer_sequence

But frankly, you might as well just include <utility>.

[jzmaddock]

@mborland ?

I'm wondering how this managed to slip through CI testing as well.

[jwakely]

I'm wondering how this managed to slip through CI testing as well.

Possible scenarios:

• <utility> has already been included before that point, so the erroneous #include <utility> is a no-op thanks to its header guard. The bug doesn't show up.
• <utility> has not been included yet, but that means the __cpp_lib_integer_sequence macro isn't defined, so you don't try to #include <utility> anyway. The bug doesn't show up.
• <utility> has not been included, but some internal std::lib header which happens to define __cpp_lib_integer_sequence has been previously included. That means the macro is defined, so you try to #include <utility> inside the boost namespace. The bug shows up.

Until last week, the third scenario wouldn't happen with libstdc++, because std::integer_sequence and its feature test macro were defined in <utility> itself. The way the macro got defined was by including that header, which means the erroneous #include is a no-op. Since last week, std::integer_sequence is in a new internal <bits/xxx.h> header that is used by <utility> but also some other headers such as <tuple>, so the third scenario is now possible.

Presumably the third scenario also didn't happen with other implementations in your tests, although I suspect this would have triggered the bug using any impl:

#include <version>
#include <boost/math/tools/mp.hpp>

It certainly fails with old versions of libstdc++ and with a recent libc++.

[jwakely]

A workaround for this bug is to #include <utility> before any use of boost 1.76.0 headers.

[mborland]

@jzmaddock Fortunately master for 1.77 is open until Wednesday so this fix is definitely worth cherry-picking.

[jzmaddock]

Test case is:

#include <version>
#include <boost/math/tools/mp.hpp>

Note that if we replace boost/math/tools/mp.hpp with either of the public headers which include it: boost/math/differentiation/autodiff.hpp or boost/math/policies/policy.hpp then I don't see the issue (with gcc-10 at least), as these include albeit inadvertently via . So it's not quite as grievous as it first appears, but does need fixing ASAP.

[jzmaddock]

Failing CI are server network issues, merging...

[pdimov]

index_sequence seems to be defined twice.

math/include/boost/math/tools/mp.hpp

Lines 356 to 357 in 3e46eba

	template<std::size_t... I>
	using index_sequence = integer_sequence<std::size_t, I...>;

and

math/include/boost/math/tools/mp.hpp

Lines 429 to 430 in 3e46eba

	template<std::size_t... I>
	using index_sequence = integer_sequence<std::size_t, I...>;

[jwakely]

then I don't see the issue (with gcc-10 at least), as these include albeit inadvertently via .

(N.B. there's an HTML escaping issue here)

Right, but with GCC's current trunk it fails much more readily, because <algorithm> no longer includes <utility> e.g. you get errors for realistic use cases like:

#include <boost/math/distributions/hypergeometric.hpp>
boost::math::hypergeometric_distribution dist(50, 50, 500);

Admittedly GCC trunk isn't going to be released until Q2 2022, but it's likely to start appearing in distros sooner than that (maybe late 2021).

[jzmaddock]

index_sequence seems to be defined twice.

You're correct - good catch, duplicate typedefs are allowed, but we shouldn't do that, will submit a fresh PR for that ASAP.

Right, but with GCC's current trunk it fails much more readily, because no longer includes e.g. you get errors for realistic use cases like:

Nod. It's asking for trouble.

[jzmaddock]

index_sequence seems to be defined twice.

See #671