|
Boost : |
Subject: [boost] [concept_check] stl_concept_covering - compiler, stdlib, boost, or test issue?
From: James E. King III (jking_at_[hidden])
Date: 2018-07-20 13:25:22
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_ar
chetype<boost::null_archetype<int> >, 0>::reference' and 'const
boost::equality_comparable2_second_archetype<boost::null_archetype<int> >')
if (*__first == __value_)
~~~~~~~~~~ ^ ~~~~~~~~
test/stl_concept_covering.cpp:152:15: note: in instantiation of function
template specialization
'std::__1::find<boost::input_iterator_archetype<boost::equalit
y_comparable2_first_archetype<boost::null_archetype<int> >, 0>,
boost::equality_comparable2_second_archetype<boost::null_archetype<int> >
>' requested here
in = std::find(in, in, value);
Full log with gcc-7.3.0 here:
https://travis-ci.org/boostorg/concept_check/jobs/404203085#L1517
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.
Any thoughts you could share on this would be appreciated.
The PR with all the build jobs showing errors can be found here:
https://github.com/boostorg/concept_check/pull/13
Thanks,
Jim
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk