Reduced:

struct c { static constexpr bool value = false; };

template <typename a> a declval();

template <typename g, typename = decltype(declval<g>() = 1)>   // #1
  void h(int);

template <typename>
  c h(...);

template<typename T> using i = decltype(h<T>(0));

struct k {
  k(const k &) = default;
  void operator=(k &&) = delete;
};
struct l : k {
  using k::operator=;   // #2
};

struct G {
  G(const G &);
  l q;
};

int j = i<G>::value;

G::G(const G &) = default;



x.cc:28:1: note: ‘G::G(const G&)’ is implicitly deleted because the default definition would be ill-formed:
 G::G(const G &) = default;
 ^
x.cc:28:1: error: use of deleted function ‘constexpr l::l(const l&)’
x.cc:17:7: note: ‘constexpr l::l(const l&)’ is implicitly declared as deleted because ‘l’ declares a move constructor or move assignment operator
 class l : k {
       ^


The error is malformed for a start, we issue a note that doesn't follow any error.

There seem to be two things involved here. The error is apparently triggered by the SFINAE check at #1 which should silently fail instead of giving an error. It seems to be an error because of the "using k::operator=;" line at #2 which should have no effect.

Slight correction: the using-declaration doesn't have no effect in general, but it shouldn't change the result of this program.

Given the file name used in the original report and how this bug was mentioned in the chromium-packager mailing list, I think this is a duplicate of bug 70431.

They don't look like duplicates to me. PR 70431 involves a union, no SFINAE, and a completely different error message.

Sorry if my comment was too coarse-grained. My hypothesis that this is a duplicate comes from playback_image_provider.ii looking like Chromium's playback_image_provider.cc, which was failing to build with GCC when a copy constructor was not defined inline (just like the union from bug 70431).

My reduced testcase from the original Chromium code (without templates) looks like this:

-----
struct S1 {
  S1& operator=(const S1&) = default;
  S1& operator=(S1&&) = default;
};

struct S2 {
  S2() = default;
  S2(const S2&);
  S1 m;
};

S2::S2(const S2&) = default;
-----

x.cc:12:1: note: ‘S2::S2(const S2&)’ is implicitly deleted because the default definition would be ill-formed:
 S2::S2(const S2&) = default;
 ^~
x.cc:12:1: error: use of deleted function ‘constexpr S1::S1(const S1&)’
x.cc:1:8: note: ‘constexpr S1::S1(const S1&)’ is implicitly declared as deleted because ‘S1’ declares a move constructor or move assignment operator
 struct S1 {
        ^~

The error goes away if S2's copy constructor is declared inline.

(In reply to Raphael Kubo da Costa from comment #5)
> Sorry if my comment was too coarse-grained. My hypothesis that this is a
> duplicate comes from playback_image_provider.ii looking like Chromium's
> playback_image_provider.cc, which was failing to build with GCC when a copy
> constructor was not defined inline (just like the union from bug 70431).

Not every example with a non-inline copy constructor is the same though.

> My reduced testcase from the original Chromium code (without templates)
> looks like this:
> 
> -----
> struct S1 {
>   S1& operator=(const S1&) = default;
>   S1& operator=(S1&&) = default;
> };
> 
> struct S2 {
>   S2() = default;
>   S2(const S2&);
>   S1 m;
> };
> 
> S2::S2(const S2&) = default;
> -----
> 
> x.cc:12:1: note: ‘S2::S2(const S2&)’ is implicitly deleted because the
> default definition would be ill-formed:
>  S2::S2(const S2&) = default;
>  ^~
> x.cc:12:1: error: use of deleted function ‘constexpr S1::S1(const S1&)’
> x.cc:1:8: note: ‘constexpr S1::S1(const S1&)’ is implicitly declared as
> deleted because ‘S1’ declares a move constructor or move assignment operator
>  struct S1 {
>         ^~
> 
> The error goes away if S2's copy constructor is declared inline.

Because that's what the C++ standard requires. A copy constructor that is defined as defaulted outside the class body is ill-formed if it would be implicitly deleted. If it's defaulted on its first declaration (i.e. inside the class body) then it is defined as deleted.

Your example is not valid, and is rejected by GCC and Clang and EDG.

(In reply to Jonathan Wakely from comment #6)
> Your example is not valid, and is rejected by GCC and Clang and EDG.

Ugh, I forgot to test it with clang before posting my comment. I stand corrected. 

Is it relevant that your testcase builds fine when G's copy constructor is inlined?

(In reply to Raphael Kubo da Costa from comment #7)
> Is it relevant that your testcase builds fine when G's copy constructor is
> inlined?

Yes, it seems to be. The checks done for the out-of-class defaulted definition fail for bogus reasons.

I can confirm that the PR is blocking Chromium build in openSUSE.
Do I understand that correctly Jonathan that it's an issue in GCC? Or is it an invalid code snippet?

(In reply to Martin Liška from comment #9)
> I can confirm that the PR is blocking Chromium build in openSUSE.

From a Chromium perspective (where I'm coming from), it shouldn't be. The problematic bits were changed in Chromium in https://chromium-review.googlesource.com/c/chromium/src/+/944403 because of this bug and the commit just be backported to unblock your package builds.

(In reply to Martin Liška from comment #9)
> Do I understand that correctly Jonathan that it's an issue in GCC? Or is it
> an invalid code snippet?

This is a GCC bug. The code should be accepted without an error.

FWIW, the snippet from comment #1 builds fine with GCC >= 9.1 at least.

It was fixed by:

    PR c++/89381 - implicit copy and using-declaration.
    
    Here the used base<int>::operator= gets into the list of foo's bindings for
    operator=, but it shouldn't make the copy ctor deleted.
    
            * class.c (classtype_has_move_assign_or_move_ctor_p): Don't consider
            op= brought in by a using-declaration.
    
    From-SVN: r269442

Looks like a dup of PR c++/89381.

That fix has also been backported for GCC 8.4

*** This bug has been marked as a duplicate of bug 89381 ***