https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80245
Jonathan Wakely <redi at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution|--- |DUPLICATE
--- Comment #1 from Jonathan Wakely <redi at gcc dot gnu.org> ---
Reduced:
struct B { void operator()(char){} };
template <int>
struct base : B {};
struct ob : base<0>, base<1>
{
using base<0>::operator(); // char
using base<1>::operator(); // char
};
template <class...>
using void_t = void;
template <class, class = void>
struct is_ambiguous { };
template <class T>
struct is_ambiguous<T, void_t<decltype(T{}('a'))>> { };
is_ambiguous<ob> test;
ambig.cc: In instantiation of 'struct is_ambiguous<ob>':
ambig.cc:21:18: required from here
ambig.cc:19:43: error: 'B' is an ambiguous base of 'ob'
struct is_ambiguous<T, void_t<decltype(T{}('a'))>> { };
~~~^~~~~
ambig.cc:19:43: error: 'B' is an ambiguous base of 'ob'
> The request for an ambiguous member function call produces a SFINAE-friendly
> context on `clang++5`, allowing the `is_ambiguous` detection to properly
> take place.
I don't think the problem for GCC is that it's not a SFINAE-friendly context,
it's that it gives a different answer in the SFINAE context and when
instantiated. So this is the same as PR 84689.
*** This bug has been marked as a duplicate of bug 84689 ***
