[Phoenix] lambda_tests.test fails on gcc 4.3-4.8 with BOOST_RESULT_OF_USE_DECLTYPE

First, thanks Eric for fixing incompatibility between Phoenix and decltype-based result_of. This is really a great fix! I ran Phoenix test-suite on * clang 3.1, 3.2 (trunk) * gcc 4.4-4.7, 4.8 (experimental) with * C++03, C++11 + BOOST_RESULT_OF_USE_DECLTYPE, C++11 + BOOST_RESULT_OF_USE_TR1 The only failure is lambda_tests.test (i.e. scope/lambda_tests.cpp) on gcc 4.4-4.7 with C++11 + BOOST_RESULT_OF_USE_DECLTYPE. Is this caused by deficiency of N3276 decltype support? P.S. What was the main reason for the incompatibility between Phoenix and decltype-based result_of? And how did you fix it? Regards, Michel

On 10/5/2012 10:50 PM, Michel Morin wrote:
First, thanks Eric for fixing incompatibility between Phoenix and decltype-based result_of. This is really a great fix!
I ran Phoenix test-suite on * clang 3.1, 3.2 (trunk) * gcc 4.4-4.7, 4.8 (experimental) with * C++03, C++11 + BOOST_RESULT_OF_USE_DECLTYPE, C++11 + BOOST_RESULT_OF_USE_TR1
The only failure is lambda_tests.test (i.e. scope/lambda_tests.cpp) on gcc 4.4-4.7 with C++11 + BOOST_RESULT_OF_USE_DECLTYPE. Is this caused by deficiency of N3276 decltype support?
I don't know. Maybe Thomas can have a look. I tried to understand the code for Phoenix lambda and broke my brain. :-P This test also fails on msvc when BOOST_RESULT_OF_USE_DECLTYPE is defined.
P.S. What was the main reason for the incompatibility between Phoenix and decltype-based result_of? And how did you fix it?
A host of small problems, most of them pretty simple. Here's an example: struct Fun { typedef void result_type; template<typename T> void operator()(T & t) const {} }; struct S {}; typedef boost::result_of<Fun(S)>::type should_be_void_t; The trouble with this is that result_of will create an rvalue of type S and try to pass that to Fun's operator(). It will fail because rvalues don't bind to non-const lvalues. But this works fine with TR1 result_of. For Phoenix, the fix was usually to make the function parameter a const ref. In other cases, the right fix might be to change the result_of invocation to: boost::result_of<Fun(S &)>. -- Eric Niebler BoostPro Computing http://www.boostpro.com

Eric Niebler :
I ran Phoenix test-suite on * clang 3.1, 3.2 (trunk) * gcc 4.4-4.7, 4.8 (experimental) with * C++03, C++11 + BOOST_RESULT_OF_USE_DECLTYPE, C++11 + BOOST_RESULT_OF_USE_TR1
The only failure is lambda_tests.test (i.e. scope/lambda_tests.cpp) on gcc 4.4-4.7 with C++11 + BOOST_RESULT_OF_USE_DECLTYPE. Is this caused by deficiency of N3276 decltype support?
I don't know. Maybe Thomas can have a look. I tried to understand the code for Phoenix lambda and broke my brain. :-P This test also fails on msvc when BOOST_RESULT_OF_USE_DECLTYPE is defined.
I did additional tests: on clang 2.8-3.0 in a C++11 mode with BOOST_RESULT_OF_USE_DECLTYPE, lambda_tests.test also failed. During the tests, I found that runtime errors (BOOST_TEST failures) happen in some tests (e.g. scope/let_tests.cpp) when compiling them with optimization flag (-O2 or -O3) on both gcc (except gcc 4.5) and clang. The runtime failures happen both in C++03 and C++11 modes. I don't know if this is related to Boost.Proto, but I report this here just in case.
P.S. What was the main reason for the incompatibility between Phoenix and decltype-based result_of? And how did you fix it?
A host of small problems, most of them pretty simple. Here's an example:
struct Fun { typedef void result_type;
template<typename T> void operator()(T & t) const {} };
struct S {}; typedef boost::result_of<Fun(S)>::type should_be_void_t;
The trouble with this is that result_of will create an rvalue of type S and try to pass that to Fun's operator(). It will fail because rvalues don't bind to non-const lvalues. But this works fine with TR1 result_of.
For Phoenix, the fix was usually to make the function parameter a const ref. In other cases, the right fix might be to change the result_of invocation to: boost::result_of<Fun(S &)>.
I see. Thanks for sharing the information! Regards, Michel

On 10/7/2012 12:04 AM, Michel Morin wrote:
Eric Niebler :
I ran Phoenix test-suite on * clang 3.1, 3.2 (trunk) * gcc 4.4-4.7, 4.8 (experimental) with * C++03, C++11 + BOOST_RESULT_OF_USE_DECLTYPE, C++11 + BOOST_RESULT_OF_USE_TR1
The only failure is lambda_tests.test (i.e. scope/lambda_tests.cpp) on gcc 4.4-4.7 with C++11 + BOOST_RESULT_OF_USE_DECLTYPE. Is this caused by deficiency of N3276 decltype support?
I don't know. Maybe Thomas can have a look. I tried to understand the code for Phoenix lambda and broke my brain. :-P This test also fails on msvc when BOOST_RESULT_OF_USE_DECLTYPE is defined.
I did additional tests: on clang 2.8-3.0 in a C++11 mode with BOOST_RESULT_OF_USE_DECLTYPE, lambda_tests.test also failed.
It could be related to support for N3276, but it's hard to say.
During the tests, I found that runtime errors (BOOST_TEST failures) happen in some tests (e.g. scope/let_tests.cpp) when compiling them with optimization flag (-O2 or -O3) on both gcc (except gcc 4.5) and clang. The runtime failures happen both in C++03 and C++11 modes. I don't know if this is related to Boost.Proto, but I report this here just in case.
You should file this as a Phoenix bug. -- Eric Niebler BoostPro Computing http://www.boostpro.com

Eric Niebler wrote:
I don't know. Maybe Thomas can have a look. I tried to understand the code for Phoenix lambda and broke my brain. :-P This test also fails on msvc when BOOST_RESULT_OF_USE_DECLTYPE is defined.
I did additional tests: on clang 2.8-3.0 in a C++11 mode with BOOST_RESULT_OF_USE_DECLTYPE, lambda_tests.test also failed.
It could be related to support for N3276, but it's hard to say.
I made a ticket for this. #7481 (lambda_tests.test fails to compile with BOOST_RESULT_OF_USE_DECLTYPE) https://svn.boost.org/trac/boost/ticket/7481
During the tests, I found that runtime errors (BOOST_TEST failures) happen in some tests (e.g. scope/let_tests.cpp) when compiling them with optimization flag (-O2 or -O3) on both gcc (except gcc 4.5) and clang. The runtime failures happen both in C++03 and C++11 modes. I don't know if this is related to Boost.Proto, but I report this here just in case.
You should file this as a Phoenix bug.
Done. #7480 (Runtime failures in let_tests.test) https://svn.boost.org/trac/boost/ticket/7480 Regards, Michel
participants (2)
-
Eric Niebler
-
Michel Morin