[test, parameter, fusion] en/disable_if name clash in trunk
it seems that the new boost::unit_test::decorator::enable_if, introduced in [1] clashes with boost::enable_if under certain circumstances. this currently breaks the boost.heap testsuite (see [2]). maybe the test/parameter/fusion maintainers could discuss, how that can be resolved? thanks, tim [1] https://svn.boost.org/trac/boost/changeset/74663 [2] http://www.boost.org/development/tests/trunk/developer/heap.html
Tim Blechmann <tim <at> klingt.org> writes:
it seems that the new boost::unit_test::decorator::enable_if, introduced in [1] clashes with boost::enable_if under certain circumstances. this currently breaks the boost.heap testsuite (see [2]).
How does it manages to locate enable_if in namespace boost::unit_test::decorator? Do you have any using statements around? Gennadiy
it seems that the new boost::unit_test::decorator::enable_if, introduced in [1] clashes with boost::enable_if under certain circumstances. this currently breaks the boost.heap testsuite (see [2]).
How does it manages to locate enable_if in namespace boost::unit_test::decorator?
no idea
Do you have any using statements around?
one of the test sources contains a `using namespace boost::heap'. but also the tests without this using statement fail. thanks, tim
Tim Blechmann <tim <at> klingt.org> writes:
it seems that the new boost::unit_test::decorator::enable_if, introduced in [1] clashes with boost::enable_if under certain circumstances. this currently breaks the boost.heap testsuite (see [2]).
How does it manages to locate enable_if in namespace boost::unit_test::decorator?
no idea
How difficult is to create a small example illustrating the issue? The issue might come up again in user's code. Gennadiy
it seems that the new boost::unit_test::decorator::enable_if, introduced in [1] clashes with boost::enable_if under certain circumstances. this currently breaks the boost.heap testsuite (see [2]).
maybe the test/parameter/fusion maintainers could discuss, how that can be resolved?
ping the deadline for merging new libraries is in one week. i'd like to merge boost.heap into the release branch for 1.49, but i won't do it, if the testsuite does not build, because the enable_if name clash. i have submitted patches to the tracker, but i won't mess with other people's code. best, tim
on Sun Dec 11 2011, Tim Blechmann <tim-AT-klingt.org> wrote:
it seems that the new boost::unit_test::decorator::enable_if, introduced in
[1] clashes with boost::enable_if under certain circumstances. this currently breaks the boost.heap testsuite (see [2]).
maybe the test/parameter/fusion maintainers could discuss, how that can be resolved?
ping
the deadline for merging new libraries is in one week. i'd like to merge boost.heap into the release branch for 1.49, but i won't do it, if the testsuite does not build, because the enable_if name clash.
i have submitted patches to the tracker, but i won't mess with other people's code.
I haven't answered becase it seems like clearly a Boost.Test issue. Am I mistaken? If something needs to be done to Boost.Parameter, you have my blessing to go ahead. -- Dave Abrahams BoostPro Computing http://www.boostpro.com
it seems that the new boost::unit_test::decorator::enable_if, introduced in
[1] clashes with boost::enable_if under certain circumstances. this currently breaks the boost.heap testsuite (see [2]).
maybe the test/parameter/fusion maintainers could discuss, how that can be resolved?
ping
the deadline for merging new libraries is in one week. i'd like to merge boost.heap into the release branch for 1.49, but i won't do it, if the testsuite does not build, because the enable_if name clash.
i have submitted patches to the tracker, but i won't mess with other people's code.
I haven't answered becase it seems like clearly a Boost.Test issue. Am I mistaken? If something needs to be done to Boost.Parameter, you have my blessing to go ahead.
there are boost::enable_if and boost::unit_test::decorator::enable_if, which is pulled into boost::unit_test. it breaks usage of enable_if because the compiler cannot figure out, which enable_if to use: namespace boost { namespace mpl { template <class T> struct lambda< T , typename enable_if< parameter::aux::is_name_tag<T>, parameter::aux::lambda_tag >::type maybe it is a bug in boost.test, but it can be worked around in boost.parameter and boost.fusion by specifying the full name boost::enable_if. tim
on Sun Dec 11 2011, Tim Blechmann <tim-AT-klingt.org> wrote:
it seems that the new boost::unit_test::decorator::enable_if,
introduced in
[1] clashes with boost::enable_if under certain circumstances. this currently breaks the boost.heap testsuite (see [2]).
maybe the test/parameter/fusion maintainers could discuss, how that can be resolved?
ping
the deadline for merging new libraries is in one week. i'd like to merge boost.heap into the release branch for 1.49, but i won't do it, if the testsuite does not build, because the enable_if name clash.
i have submitted patches to the tracker, but i won't mess with other people's code.
I haven't answered becase it seems like clearly a Boost.Test issue. Am I mistaken? If something needs to be done to Boost.Parameter, you have my blessing to go ahead.
there are boost::enable_if and boost::unit_test::decorator::enable_if, which is pulled into boost::unit_test.
it breaks usage of enable_if because the compiler cannot figure out, which enable_if to use:
namespace boost { namespace mpl { template <class T> struct lambda< T , typename enable_if< parameter::aux::is_name_tag<T>, parameter::aux::lambda_tag >::type
maybe it is a bug in boost.test, but it can be worked around in boost.parameter and boost.fusion by specifying the full name boost::enable_if.
If it's a bug in Boost.Test, it should be fixed there. However, if you can't get Gennadiy to make the fix, go ahead and adjust Boost.Parameter. -- Dave Abrahams BoostPro Computing http://www.boostpro.com
On 12/11/2011 8:30 PM, Tim Blechmann wrote:
maybe it is a bug in boost.test, but it can be worked around in boost.parameter and boost.fusion by specifying the full name boost::enable_if.
If you have a boost fusion patch, I'll gladly apply them if it does not uglify the code too much ;-) Cheers, -- Joel de Guzman http://www.boostpro.com http://boost-spirit.com
maybe it is a bug in boost.test, but it can be worked around in boost.parameter and boost.fusion by specifying the full name boost::enable_if. If you have a boost fusion patch, I'll gladly apply them if it does not uglify the code too much ;-)
patch is here [1]. there is one comment that the patch should not change preprocessed files. however i don't see how the specific file is auto- generated. tim [1] https://svn.boost.org/trac/boost/ticket/6215
On 12/12/2011 6:50 PM, Tim Blechmann wrote:
maybe it is a bug in boost.test, but it can be worked around in boost.parameter and boost.fusion by specifying the full name boost::enable_if. If you have a boost fusion patch, I'll gladly apply them if it does not uglify the code too much ;-)
patch is here [1]. there is one comment that the patch should not change preprocessed files. however i don't see how the specific file is auto- generated.
tim
Don't edit the auto-generated files. You have to prepare another patch adding #define BOOST_FUSION_DONT_USE_PREPROCESSED_FILES before anything else in your test code to make fusion not use the PP-ized files. Regards, -- Joel de Guzman http://www.boostpro.com http://boost-spirit.com
maybe it is a bug in boost.test, but it can be worked around in boost.parameter and boost.fusion by specifying the full name boost::enable_if.
If you have a boost fusion patch, I'll gladly apply them if it does not uglify the code too much ;-)
patch is here [1]. there is one comment that the patch should not change preprocessed files. however i don't see how the specific file is auto- generated.
tim
Don't edit the auto-generated files. You have to prepare another patch adding #define BOOST_FUSION_DONT_USE_PREPROCESSED_FILES before anything else in your test code to make fusion not use the PP-ized files.
maybe my question was not clear: how are the files auto-generated? tim
On 12/13/2011 6:24 PM, Tim Blechmann wrote:
maybe it is a bug in boost.test, but it can be worked around in boost.parameter and boost.fusion by specifying the full name boost::enable_if.
If you have a boost fusion patch, I'll gladly apply them if it does not uglify the code too much ;-)
patch is here [1]. there is one comment that the patch should not change preprocessed files. however i don't see how the specific file is auto- generated.
tim
Don't edit the auto-generated files. You have to prepare another patch adding #define BOOST_FUSION_DONT_USE_PREPROCESSED_FILES before anything else in your test code to make fusion not use the PP-ized files.
maybe my question was not clear: how are the files auto-generated?
You don't need to know. Just prepare the patches the way I outlined above and I'll do the rest. Regards, -- Joel de Guzman http://www.boostpro.com http://boost-spirit.com
On Tuesday 13 December 2011 18:27:12 Joel de Guzman wrote:
On 12/13/2011 6:24 PM, Tim Blechmann wrote:
maybe it is a bug in boost.test, but it can be worked around in boost.parameter and boost.fusion by specifying the full name boost::enable_if.
If you have a boost fusion patch, I'll gladly apply them if it does not uglify the code too much ;-)
patch is here [1]. there is one comment that the patch should not change preprocessed files. however i don't see how the specific file is auto- generated.
tim
Don't edit the auto-generated files. You have to prepare another patch adding #define BOOST_FUSION_DONT_USE_PREPROCESSED_FILES before anything else in your test code to make fusion not use the PP-ized files.
maybe my question was not clear: how are the files auto-generated?
You don't need to know. Just prepare the patches the way I outlined above and I'll do the rest.
Regards,
Tim Blechm ann <tim <at> klingt.org> writes:
the deadline for merging new libraries is in one week. i'd like to merge boost.heap into the release branch for 1.49, but i won't do it, if the testsuite does not build, because the enable_if name clash.
i have submitted patches to the tracker, but i won't mess with other people's code.
I am on vacation till wendsday. If this is patch for boost.test I'l be able to take a look once I am back. The easiest fix seems to be to add boost:: in front of enable_if. Gennadiy
participants (4)
-
Dave Abrahams -
Gennadiy Rozental -
Joel de Guzman -
Tim Blechmann