Help needed debugging std::is_convertible problem (PR 65760)

On 17/04/15 01:03 +0200, Daniel Krügler wrote:
>2015-04-16 14:33 GMT+02:00 Jonathan Wakely <jwakely.gcc@gmail.com>:
>> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65760
>>
>> I don't understand why commenting out *any one* of the lines marked
>> (1), (2), (3), (4) causes this to compile:
>>
>> #include <functional>
>>
>> struct C {
>>     C() = default;
>>
>>     C(std::function<C(int)>);  // (1)
>>     C(std::function<C(int, int)>); // (2)
>>     template <class T> C operator () (T&&); // (3)
>>     template <class T> C operator () (T&&, T&&); // (4)
>> };
>
>My current understanding of the state of affairs is still complete in
>some details, but let me still throw in my 2 cents: The compiler sees
>an object of C constructed by an rvalue of C. Now we have - in
>addition to the copy/move constructors - two corresponding pairs of
>function call operator and converting constructor to consider. Let me
>simplify the situation a bit more by removing the additional layer of
>template deduction of the call operators to:
>
>struct C
>{
>  C() = default;
>
>  C(std::function<C(int)>);  // (1)
>  C(std::function<C(int, int)>); // (2)
>  C operator()(int); // (3)
>  C operator()(int, int); // (4)
>};
>
>In the presence of all four members the compiler is allowed (I think
>by [temp.inst] p7) to instantiate one or both of the different
>std::function specializations, because it has to respect possible
>conversions. When this happens, the converting template constructor
>declaration of std::function also needs to be instantiated. While
>doing this, we come to the point where within the SFINAE condition
>std::is_convertible<C, C> needs to be instantiated, effectively
>leading to a situation that we have two different contexts, in which
>the compiler needs to evaluate the result the self-conversion of C, C
>never becoming completed to realize that during that attempt.
>
>If *any* of the four members is missing, we don't have the situation
>that two conversion sequences based on function template deduction
>need to be partially ordered, we have only the non-template copy/move
>constructor against exactly one possible function template. For this
>to order, the compiler doesn't require instantiation of the converting
>constructor of std::function.

[...]

>Nonetheless, my understanding of your fix is that it actually is not
>conforming to what the standard currently requires (This seems to
>match you own thinking expressed above), because [func.wrap.func.con]
>p8 requires:
>
>"shall not participate in overload resolution unless f is Callable
>(20.9.12.2) for argument types ArgTypes... and return type R."
>
>and if we unroll this against the definition Callable (ending in
>[func.require] p2) we finally end up in a required test whether the
>return type of the invokable thingee has a value of
>std::is_convertible<C, C>::value == true (C has the role of the return
>type R). This is so, *even*, if LWG issue
>
>http://cplusplus.github.io/LWG/lwg-active.html#2420
>
>would be fixed as described, because we have no void return type involved here.
>
>My current position is that we presumably have a Standard Library
>issue lurking around, because I see no way how any library can
>implement std::function without breaking this seemingly valid example
>case. Either the Standard Library needs to express stronger
>constraints on the return type R of std::function<R(ArgTypes...)> (so
>to make the example invalid), or - what I would currently prefer - the
>library would need to reduce the SFINAE constraints of the
>std::function template constructor basically ending in not requiring
>that R is complete, or in other words: not requiring the final part of
>the Callable test involving the implicit conversion of the functor
>result to the described result type R of
>std::function<R(ArgTypes...)>.
>
>To follow the intention of std::functions design, the Library could
>require that when the constructor definition of
>
>template<class F> function(F);
>
>becomes instantiated, the current SFINAE requirements are to be
>tested, possibly making this definition instantiation ill-formed.
>
>Summarizing this, I consider your suggested resolution as useful for
>practical reasons.

While I agree with Daniel that my suggested fix may not be strictly
conforming, I think it is worth doing anyway, so I'm committing it.

Tested powerpc64le-linux, committed to trunk.