[boost] Re: is_convertible for intel 7.1 and 8.0

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