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

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

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

Boost - Dev mailing list
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

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

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

Boost - Dev mailing list
On 20 July 2018 at 16:25, James E. King III via Boost <[hidden email]
> 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*

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

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

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
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.


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

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

Boost - Dev mailing list
On Fri, Jul 20, 2018 at 11:11 AM Peter Dimov via Boost <
[hidden email]> 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?

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

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

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
On Fri, Jul 20, 2018 at 11:11 AM Peter Dimov via Boost <
[hidden email]> 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

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost