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.