* 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@chello.at> writes:
David Abrahams wrote:
Douglas Gregor <dgregor@osl.iu.edu> 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