[boost] How to mark up stl_concept_covering (was: Broken failure markup)

From: David Abrahams (dave_at_[hidden])
Date: 2007-01-14 13:00:41

* I just want to point out up front that the discussion below is
* irrelevant to the question of whether failure markup and its
* processing is broken or not

Roland Schwarz <roland.schwarz_at_[hidden]> writes:

> David Abrahams wrote:
>> Douglas Gregor <dgregor_at_[hidden]> writes:
>> 
>>> |concept_check|
>>>   class_concept_fail_expected:  borland-5.6.4  borland-5.8.2  borland-5.8.2  msvc-6.5  msvc-6.5  msvc-7.0
>>>   stl_concept_covering:  borland-5.8.2  borland-5.8.2  gcc-3.3.6  gcc-3.4.5_linux  gcc-3.4.5_linux_x86_64  gcc-4.0.3_linux  gcc-4.1.0_linux  gcc-4.1.0_linux_x86_64  gcc-4.1.1_sunos_i86pc
>> 
>> Jeremy Siek checked in expected failures markup for all these tests
>> well over one week ago.  The markup looks OK to me, but the
>> failures are still showing up.  What's going on here?
>
> I don't think marking them as expected to fail on all platforms is
> the way to go.

He didn't do that for class_concept_fail_expected.  For
stl_concept_covering it's at least more appropriate than leaving them
unmarked.  Since it's mostly a test of the standard library they
should probably be removed from the Boost suite, but that's another
matter.

> I looked into the one that seemingly is causing one of the 
> stl_concept_covering tests:
>
>    {
> #if defined(__GNUC__)
>      typedef less_than_op_first_archetype<> FT;
>      typedef less_than_op_second_archetype<> T;
> #elif defined(__KCC)
>      // The KAI version of this uses a one-argument less-than function
>      // object.
>      typedef less_than_comparable_archetype<> T;
>      typedef convertible_to_archetype<T> FT;
> #endif
>      forward_iterator_archetype<FT> fi;
>      T value(dummy_cons);
>      fi = std::lower_bound(fi, fi, value);
>    }
>
> This looks very strange to me. 

Me too.

> Only __GNUC__ or __KCC ever will be able to pass. What about other
> compilers, or nothing of both defined? Why not simply disable the
> test in these cases?

Isn't that just one of many parts of this test that are broken on most
toolsets?  IIRC that's the case.  Jeremy?

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