[fusion] change on trunk breaking proto
Hi Fusion gurus. I'm chasing an elusive bug that the following Proto test has exposed: http://beta.boost.org/development/tests/trunk/developer/output/RW_WinXP_VC-b... All is well on the release branch, but on trunk, Proto's examples.cpp test is failing -- but only on MSVC! I suspect Fusion because if I replace the version of Fusion on trunk with the one on release all is well. (Caveat: when I do this, I also need to make a corresponding change to the as_callable function object in proto/transform/fold.hpp to accommodate the changed argument order of fusion::fold's functor.) It seems something is causing MSVC to prematurely instantiate a template used in a Proto transform, but I can't see what. I first suspected the recent changes to fusion::fold, but that seems not to be the case. If I just take the release version of fusion::fold, the problem still manifests. The problem must be elsewhere. Does anyone from Fusion team want to give this a crack? I'll be happy to help. -- Eric Niebler BoostPro Computing http://www.boostpro.com
Eric Niebler schrieb:
Hi Fusion gurus. I'm chasing an elusive bug that the following Proto test has exposed:
http://beta.boost.org/development/tests/trunk/developer/output/RW_WinXP_VC-b...
All is well on the release branch, but on trunk, Proto's examples.cpp test is failing -- but only on MSVC! I suspect Fusion because if I replace the version of Fusion on trunk with the one on release all is well. (Caveat: when I do this, I also need to make a corresponding change to the as_callable function object in proto/transform/fold.hpp to accommodate the changed argument order of fusion::fold's functor.) It seems something is causing MSVC to prematurely instantiate a template used in a Proto transform, but I can't see what.
I first suspected the recent changes to fusion::fold, but that seems not to be the case. If I just take the release version of fusion::fold, the problem still manifests. The problem must be elsewhere.
Does anyone from Fusion team want to give this a crack? I'll be happy to help.
Changeset 57337, in particular the change in boost/fusion/view/reverse_view/reverse_view.hpp, causes the trouble. I only tested this changeset with my default toolchain (gcc 4.4) as I did not consider any of my changes to be breaking. I am awfully sorry. The change in reverse_view.hpp causes fusion::reverse_view to always be a bidirectional access sequence, even if the underlying sequence is a random access one. This is correct behaviour according to the documentation. The problem in proto is probably caused by a bug in the VC9/VC10 compiler. The non-random-access implementation of fusion::detail::fold wrongly causes the compiler to instantiate nested template parameters of the functor. I attached a minimal sample which reproduces this problem. Interestingly, the random-access fold implementation works fine in your particular usecase, whereas my sample reproduces the problem for forward and random access sequences. I also attached a temporary workaround-patch for proto. Unfortunately I have no idea of how to "fix" fusion in the first place. BTW, compiling the examples.cpp testcase with the upcoming C++0x port of fusion and VC9 works fine. -Christopher Index: boost/proto/transform/fold.hpp =================================================================== --- boost/proto/transform/fold.hpp (revision 58271) +++ boost/proto/transform/fold.hpp (working copy) @@ -198,10 +198,11 @@ { typename when<_, Sequence>::template impl<Expr, State, Data> seq; detail::as_callable<Fun, Data> f(d); - return fusion::fold( + return fusion::detail::fold( seq(e, s, d) , typename when<_, State0>::template impl<Expr, State, Data>()(e, s, d) , f + , fusion::random_access_traversal_tag() ); } };
Christopher Schmidt wrote:
Eric Niebler schrieb:
Hi Fusion gurus. I'm chasing an elusive bug that the following Proto test has exposed:
http://beta.boost.org/development/tests/trunk/developer/output/RW_WinXP_VC-b... <snip>
Does anyone from Fusion team want to give this a crack? I'll be happy to help.
Changeset 57337, in particular the change in boost/fusion/view/reverse_view/reverse_view.hpp, causes the trouble. I only tested this changeset with my default toolchain (gcc 4.4) as I did not consider any of my changes to be breaking. I am awfully sorry.
No worries.
The change in reverse_view.hpp causes fusion::reverse_view to always be a bidirectional access sequence, even if the underlying sequence is a random access one. This is correct behaviour according to the documentation.
What is the motivation for this change? It seems to me that a reversed random-access range can and should be random-access as well.
The problem in proto is probably caused by a bug in the VC9/VC10 compiler. The non-random-access implementation of fusion::detail::fold wrongly causes the compiler to instantiate nested template parameters of the functor.
I attached a minimal sample which reproduces this problem.
You should file a bug with Microsoft and attach the preprocessed source code. I can do this if you don't know how.
Interestingly, the random-access fold implementation works fine in your particular usecase, whereas my sample reproduces the problem for forward and random access sequences. I also attached a temporary workaround-patch for proto.
Proto's fold transform should work with any forward fusion sequence, so I'm afraid I cannot apply your patch because it may break third-party code.
Unfortunately I have no idea of how to "fix" fusion in the first place.
Is reverting the change to reverse_view and option? -- Eric Niebler BoostPro Computing http://www.boostpro.com
Eric Niebler schrieb:
The change in reverse_view.hpp causes fusion::reverse_view to always be a bidirectional access sequence, even if the underlying sequence is a random access one. This is correct behaviour according to the documentation.
What is the motivation for this change? It seems to me that a reversed random-access range can and should be random-access as well.
On the one hand, that's correct. On the other hand, the documentation states that fusion::reverse_view models the bidirectional sequence concept. The random access intrinsic sequence backend implementation is also missing for fusion::reverse_view_tag. BTW, the upcoming C++0x-port of fusion has this issue fixed for all views.
The problem in proto is probably caused by a bug in the VC9/VC10 compiler. The non-random-access implementation of fusion::detail::fold wrongly causes the compiler to instantiate nested template parameters of the functor.
I attached a minimal sample which reproduces this problem.
You should file a bug with Microsoft and attach the preprocessed source code. I can do this if you don't know how.
I will file a bug myself. Thanks for the offer though :)
Interestingly, the random-access fold implementation works fine in your particular usecase, whereas my sample reproduces the problem for forward and random access sequences. I also attached a temporary workaround-patch for proto.
Proto's fold transform should work with any forward fusion sequence, so I'm afraid I cannot apply your patch because it may break third-party code.
Unfortunately I have no idea of how to "fix" fusion in the first place.
Is reverting the change to reverse_view and option?
No problem! I will have the change reverted and the documentation updated by tomorrow. -Christopher
Christopher Schmidt wrote:
Eric Niebler schrieb:
Christopher Schmidt wrote:
Unfortunately I have no idea of how to "fix" fusion in the first place.
Is reverting the change to reverse_view and option?
No problem! I will have the change reverted and the documentation updated by tomorrow.
Thanks! And thanks for tracking the problem down. -- Eric Niebler BoostPro Computing http://www.boostpro.com
Eric Niebler wrote:
Christopher Schmidt wrote:
Eric Niebler schrieb:
Christopher Schmidt wrote:
Unfortunately I have no idea of how to "fix" fusion in the first place.
Is reverting the change to reverse_view and option?
No problem! I will have the change reverted and the documentation updated by tomorrow.
Thanks! And thanks for tracking the problem down.
Thanks, Christopher! Regards, -- Joel de Guzman http://www.boostpro.com http://spirit.sf.net http://www.facebook.com/djowel Meet me at BoostCon http://www.boostcon.com/home http://www.facebook.com/boostcon
Christopher Schmidt schrieb:
The problem in proto is probably caused by a bug in the VC9/VC10 compiler. The non-random-access implementation of fusion::detail::fold wrongly causes the compiler to instantiate nested template parameters of the functor.
I attached a minimal sample which reproduces this problem. You should file a bug with Microsoft and attach the preprocessed source code. I can do this if you don't know how.
I will file a bug myself. Thanks for the offer though :)
The Microsoft compiler team confirmed the bug. Unfortunately, "it is too close to the release of VS 2010 to include a fix for this issue but we shall consider the fix for the next version of the compiler." -Christopher
On Wed, Dec 23, 2009 at 4:50 AM, Christopher Schmidt <mr.chr.schmidt@online.de> wrote:
Christopher Schmidt schrieb:
The problem in proto is probably caused by a bug in the VC9/VC10 compiler. The non-random-access implementation of fusion::detail::fold wrongly causes the compiler to instantiate nested template parameters of the functor.
I attached a minimal sample which reproduces this problem. You should file a bug with Microsoft and attach the preprocessed source code. I can do this if you don't know how.
I will file a bug myself. Thanks for the offer though :)
The Microsoft compiler team confirmed the bug. Unfortunately,
"it is too close to the release of VS 2010 to include a fix for this issue but we shall consider the fix for the next version of the compiler."
I notice that they always say that when they are never going to fix it. There are still some bugs from 2k3 that are still not fixed up to 2k10 that were ignored with that same message (but relating to 2k3)...
participants (4)
-
Christopher Schmidt -
Eric Niebler -
Joel de Guzman -
OvermindDL1