Re: [boost] Bug reports - Showstoppers and Regressions

Subject: Re: [boost] Bug reports - Showstoppers and Regressions
From: Torsten Maehne (Torsten.Maehne_at_[hidden])
Date: 2012-01-18 10:20:22

Dear Gennadiy,

thanks for your response. This is the first response at all that I get on 
ticket #6331.

On Tue, 17 Jan 2012 22:00:37 +0000, Gennadiy Rozental wrote:

> Torsten Maehne <Torsten.Maehne <at> gmx.de> writes:
>> Hello,
>> 
>> concerning regressions in Boost.Test, ticket #6331 "g++ compilation
>> error due to ambiguity between template<class Cond, class T> struct
>> boost::enable_if and class boost::unit_test::decorator::enable_if
> 
> 1. I am yet to see why this is boost.test fault and not compiler bug.

Even though, I stumpled on this bug while preparing the test case for 
ticket #6126, it was Jeroen Habraken <vexocide_at_[hidden]>, who tracked it 
down to recent changes in Boost.Test. Did you look at the test case.

---------------------------------------------------------------
#define BOOST_TEST_MODULE test_boost_test_decorator_enable_if
#include <boost/test/included/unit_test.hpp>
#include <boost/typeof/native.hpp>

BOOST_AUTO_TEST_CASE(test_dummy)
{
  // do nothing
}
---------------------------------------------------------------

It just includes two Boost headers and then fails to compile. This enough 
to make g++ 4.2.1, 4.5.3, and 4.6.2 fail to compile the test case. (clang+
+ 3.0 compiles just fine the test case). 

I'm not familiar enough with all the magic going on behind the scenes in 
Boost.Test to judge if it not changes the visibility of certain symbols 
in certain namespaces, e.g., by "using" statements. At least, just 
including into a test case:

---------------------------------------------------------------
#include <boost/test/tree/decorator.hpp>
#include <boost/typeof/native.hpp>

int main(int argc, char* argv[]) {
  return 0;
}
---------------------------------------------------------------

won't cause a compiler error. I don't know what triggers the compiler to 
look-up enable_if<Cond, T> in the other test case. 

I don't know either why the compiler sees the definition of 
boost::unit_test::decorator::enable_if in namespace boost::type_of. 

I don't know how to further analyse the issue. It's a bit frustrating to 
see that new tickets in the Boost Trac system seem to receive so few 
attention compared to other open-source project I have contributed, too. 
It's good to see that the Boost mailing lists are so much more 
responsive. :-)

It might well be a compiler bug, but seeing how long it takes that new 
compiler versions are widely deployed even on common platforms such as 
Windows, Linux, or Mac OS X -- especially in production environments, 
such issues should be fixed also in the Boost library.

> 2. I think qualifying symbols from boost namespace is right thing to do
> in any case

Well, I agree, but what is a user of the Boost libraries able to do about 
it? Using enable_if and co. without a qualifying namespace is widespread 
in the Boost sources: A grep on the Boost headers and some filtering 
shows that enable_if without a qualifying namespace identifier is used 
approx. 1000 times all over the Boost library. Qualifying all occurences 
of enable_if and co. will need a quite huge and well coordinated effort 
to be fixed by the different library authors.

I am aware that also other Boost libraries have their own enable_if 
variants. However, all seem to be templates except for the 
boost::unit_test::decorator::enable_if. Maybe therefore no problems were 
yet observed in combination with typename statements. At least that is 
how far I understand the issue.

> 3. This code is not part of the release.

This is good to hear. Boost.Test is very useful for me and I use it in 
conjunction with other Boost libraries regularly. Having it broken in a 
an official Boost release would cause me quite some headache as suddenly 
my unit tests for my own code would stop compiling for reasons I cannot 
influence.

> 
> Gennadiy
> 

Best regards,

Torsten Maehne