[concept_check] stl_concept_covering - compiler, stdlib, boost, or test issue?
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
On 20 July 2018 at 16:25, James E. King III via Boost <boost@lists.boost.org
wrote:
... except MSVC jobs interestingly enough.
Know nothing about this thread, but just a thought, testing might not necessarily pass with the latest version(s) of MSVC either, if run "permissive-", which means that eventually they are going to fail by default. degski -- *"If something cannot go on forever, it will stop" - Herbert Stein*
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.
On Fri, Jul 20, 2018 at 11:11 AM Peter Dimov via Boost < boost@lists.boost.org> wrote:
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.
What do you think about the fact that if the no_proxy version is used, all the failures resolve?
On Fri, Jul 20, 2018 at 11:11 AM Peter Dimov via Boost < boost@lists.boost.org> wrote:
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.
I was able to get all the CI builds to pass, see: https://github.com/boostorg/concept_check/pull/13 I also enabled the test on appveyor for MSVC and found a few cases where it didn't work, but not much. - Jim
participants (3)
-
degski -
James E. King III -
Peter Dimov