Boost logo

Boost :

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.


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