Boost C++ Libraries: Ticket #6331: [Boost.Test] g++ compilation error due to ambiguity between template struct boost::enable_if and class boost::unit_test::decorator::enable_if as well as the disable_if counterparts introduced after Boost 1.48.0 (up to at least svn rev. 76217)

attachment set

t0rt1e@… — Thu, 29 Dec 2011 13:37:10 GMT

attachment → test_boost_test_decorator_enable_if.cpp

test case

keywords changed

t0rt1e@… — Thu, 29 Dec 2011 21:12:42 GMT

keywords disable_if added

severity changed

t0rt1e@… — Tue, 17 Jan 2012 17:04:47 GMT

severity Problem → Regression

rogeeff@… — Wed, 18 Jan 2012 15:22:29 GMT

I am yet to see why this is boost.test fault and not compiler bug.
I think qualifying symbols from boost namespace is right thing to

do in any case

This code is not part of the release.

Gennadiy

t0rt1e@… — Wed, 18 Jan 2012 15:37:43 GMT

Replying to rogeeff@…:

I am yet to see why this is boost.test fault and not compiler bug.

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.

That said, before simply blaming the compiler, we should also make sure that it is not some bug in Boost.Test or other Boost component.

The test case just includes two Boost headers and then fails to compile with g++ 4.2.1, 4.5.3, and 4.6.2 (clang+ + 3.0 compiles just fine 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
}

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 issuing 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.

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. Therefore, I can imaging that 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.

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

t0rt1e@… — Fri, 20 Jan 2012 14:25:33 GMT

While digging into the issue, I came across the CHANGES document for g++ 4.7.0 currently under development. It states:

"G++ now correctly implements the two-phase lookup rules such that an unqualified name used in a template must have an appropriate declaration found either in scope at the point of definition of the template or by argument-dependent lookup at the point of instantiation. As a result, code that relies on a second unqualified lookup at the point of instantiation to find functions declared after the template or in dependent bases will be rejected. The compiler will suggest ways to fix affected code, and using the -fpermissive compiler flag will allow the code to compile with a warning."

Could this problem be related?

I also found a meta-bug in gcc's bug tracker (ticket #18805) grouping currently known problems around the name-lookup.

t0rt1e@… — Fri, 20 Jan 2012 14:28:49 GMT

I just tried to compile the test case with g++ version 4.7.0 20120114 (experimental). It still gives the same errors as the older g++ that I tried previously.

status changed; resolution set

Gennadiy Rozental — Fri, 20 Jan 2012 23:16:23 GMT

status new → closed
resolution → fixed

(In [76600]) Fixes #6331

status changed; resolution deleted

t0rt1e@… — Sat, 21 Jan 2012 09:36:26 GMT

status closed → reopened
resolution fixed

Thanks for finding the origin of the issue in a misplaced using namespace boost::unit_test statement in the implementation of the boost::unit_test! Unfortunately, the change set 76600 doesn't fully resolve the issue. There's another using namespace boost::unit_test statement hidden in in boost/test/impl/logged_expectations.ipp. I attach a patch, which finally allows me to compile my test case against Boost trunk.

attachment set

t0rt1e@… — Sat, 21 Jan 2012 09:38:35 GMT

attachment → test_impl_logged_expectations.ipp.patch

Patch misplaced using namespace statement in boost/test/impl/logged_expectations.ipp

t0rt1e@… — Mon, 06 Feb 2012 10:25:28 GMT

I just checked out Boost trunk rev. 76906. test_impl_logged_expectations.ipp.patch hasn't been applied to it yet to fix the misplaced using namespace statement in boost/test/impl/logged_expectations.ipp.

status changed; resolution set

Gennadiy Rozental — Sun, 04 Nov 2012 20:31:33 GMT

status reopened → closed
resolution → fixed