Re: [boost] [concept_check] stl_concept_covering - compiler, stdlib, boost, or test issue?

Subject: Re: [boost] [concept_check] stl_concept_covering - compiler, stdlib, boost, or test issue?
From: Peter Dimov (lists_at_[hidden])
Date: 2018-07-20 15:11:28

James E. King III wrote:
> Hi folks,
>
> The test stl_concept_covering is annotated with "gcc bug" on a number of 
> tests, and yet gcc 7.3.0 (with libstdc++) and clang-6.0 (with libc++ or 
> libstdc++) fail to compile this test, mostly on the sections marked as a 
> bug.
>
> For example:
>
>   "/usr/bin/clang++-6.0" -c -x 
> c++ -stdlib=libc++ -fPIC -m64 -O0 -fno-inline -Wall -g  -DBOOST_ALL_NO_LIB=1 
>  -I"../.." -o 
> "../../bin.v2/libs/concept_check/test/stl_concept_covering.test/clang-linux-6.0/debug/stl_concept_covering.o" 
> "test/stl_concept_covering.cpp"
>
> In file included from test/stl_concept_covering.cpp:9: 
> /usr/local/include/c++/v1/algorithm:999:24: error: invalid operands to
binary expression
> ('boost::input_iterator_archetype<boost::equality_comparable2_first_archetype<boost::null_archetype<int> 
>  >, 0>::reference' and 'const 
> boost::equality_comparable2_second_archetype<boost::null_archetype<int> 
>  >')
>         if (*__first == __value_)
>             ~~~~~~~~~~ ^  ~~~~~~~~

...

> What's interesting is that if I change the type of in to an 
> input_iterator_archetype_no_proxy the test passes.  When I look at the 
> concept_archetypes I see that input_iterator_archetype is a template with 
> a default parameter, but also defines "reference" as a structure with an 
> operator(), instead of using a typedef which is what I usually see done.
>
> So this makes me wonder if it's really a compiler issue (both compilers 
> and std C++ libs complain the same way though) or if the archetype is 
> invalid. I'm not sure the best course of action.  It does cause most CI 
> build jobs to fail, except MSVC jobs interestingly enough.

I get the same error with MSVC, it's just that the test is guarded by

// This file doesn't work on other compilers.
#if defined(__GNUC__) || defined(__KCC)

The compilers are correct, but so is the archetype. Input iterator 
requirements say that *it is convertible to the value_type, and it is, in 
our case. The problem however is that op== is a template and the first 
argument fails deduction. std::find is specified in terms of the exact 
expression `*it == value`, so if it doesn't compile (and it doesn't), 
`find(it, it, value)` won't compile either.

It's not clear to me what needs to be done here. The fact that the STL's ad 
hoc algorithm requirements are not cleanly expressible in a rigorous manner 
has been rediscovered by every attempt of conceptifying it.