Boost logo

Boost :

From: David Abrahams (dave_at_[hidden])
Date: 2003-11-19 22:27:45


Beman Dawes <bdawes_at_[hidden]> writes:

> At 06:14 PM 11/19/2003, David Abrahams wrote:
> >Beman Dawes <bdawes_at_[hidden]> writes:
> >
> >> At 01:44 PM 11/19/2003, David Abrahams wrote:
> >>
> >> >David Abrahams <dave_at_[hidden]> writes:
> >> >
> >> >In other words, it's breaking more than just is_convertible_test:
> >> >is_convertible itself is effectively broken.
> >> >
> >> >Specifically, I'd like to find another way to fix the other problems
> >> >which doesn't break is_convertible, but without more info it's pretty
> >> >hard to do. Resolving the iterator library issues depends on this.
> >>
> >> Someone needs to take is_convertible.hpp under their wing.
> >>
> >> It isn't clear to me from reading the comments on the long chain of
> >> #if/elif's which implementation is the one that is supposed to be
> >> standards conforming. It would help if that were clearly indicated.
> >>
> >> Some workarounds seem to be applied regardless of compiler version.
> >> Particularly, __GNUC__, __IBMCPP__, and one of the __BORLANDC__ uses.
> >>
> >> Once those aspects are on firmer ground it might be a bit easier to
> >> see where Intel fits in. Anyone making changes needs to make sure the
> >> fixes don't break apparently unrelated tests in other libraries.
> >
> >It seems as though you're saying I can't fix the Intel problem
> >introduced by your patch so that my other library goes back to being
> >non-broken without also addressing all of these other compilers and
> >"taking is_convertible under my wing".
>
> No, the two comments were unrelated.
>
> >Since I don't have one of those (IBM) and only have an outdated
> >version of another (Borland) that doesn't seem reasonable to me.
>
> Each of the comments above are separate. It should be possible to
> comment which implementation is the standards conforming one without
> dealing with the GNU, IBM, and Borland issues.
>
> >It's easy enough to make sure that any changes made are limited to
> >Intel. The patch you made broke is_convertible both for the type
> >traits tests and for its use in the iterator library; that's something
> >we know and can demonstrate.
>
> No, iterators was one of the libraries that were reporting failures
> until the patch was applied. The patch cleared Intel errors in
> multiple libraries. See list below.

Hmm, my problem is that I'm updating that library now and all of the
failures you've shown other than tricky_incomplete_type_test seem to
be dependent on it. Now the patch *breaks* my tests if I leave it in.
Furthermore tricky_incomplete_type_test is a separate test precisely
because it's a corner case which many compilers can't handle. It's
probably not a good idea to sacrifice is_convertible to get it to
work.

> > It seems reasonable to me that until you
> >can give some indication of *specifically* what the patch was
> >"fixing", it should be rolled back.
>
> Before the patch, a number of tests were failing. The first error
> message was:
>
> C:\boost\site\boost/type_traits/is_convertible.hpp(173): error:
> incomplete type is not allowed
>
> Tests that failed before the patch included:
>
> utility/reverse_iterator_example.cpp
> utility/indirect_iterator_example.cpp
> utility/counting_iterator_example.cpp
> iterator\test\reverse_iterator_test.cpp
> iterator\test\filter_iterator_test.cpp
> iterator\test\indirect_iterator_test.cpp
> iterator\test\iterator_adaptor_test.cpp
> iterator\test\iterator_adaptor_cc.cpp
> iterator\test\is_convertible_fail.cpp
> type_traits\test\tricky_incomplete_type_test.cpp
> multi_array/test/resize.cpp
> multi_array/test/stl_interaction.cpp
> etc.

That's *very* strange because I certainly tested the iterators
library on intel5, intel6, intel7 and intel8 when I committed it to
the HEAD and *all* tests that were expected to pass, were passing.

It would be very helpful if you could list some other tests which
were not dependent on the iterators library.

> I can send you the bjam log file from just before the patch was
> applied if you'd like.

It might be a good idea.

> If rolling the patch back fixes some fails without adding any new
> fails, then go for it!

I think I still need more data :(

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com

Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk