[Bug c++/114764] New: noexcept on a friend complains about incomplete type

[Bug c++/114764] New: noexcept on a friend complains about incomplete type

[dangelog at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114764

            Bug ID: 114764
           Summary: noexcept on a friend complains about incomplete type
           Product: gcc
           Version: 14.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: dangelog at gmail dot com
  Target Milestone: ---

Testcase:

struct S
{
    S(int) noexcept;

           void f() noexcept(noexcept(S(42)));
    friend void g() noexcept(noexcept(S(42)));
};


https://godbolt.org/z/qn5Gs4M63



GCC 14 trunk rejects with:

<source>:6:43: error: invalid use of incomplete type 'struct S'
    6 |     friend void g() noexcept(noexcept(S(42)));
      |                                           ^
<source>:1:8: note: definition of 'struct S' is not complete until the closing
brace
    1 | struct S
      |        ^
Compiler returned: 1



But that does not seem to be accurate:
https://eel.is/c++draft/class.mem.general#7 says "A complete-class context of a
class (template) is a [...] noexcept-specifier ([except.spec]) [...]  within
the member-specification of the class or class template." and a friend
declaration/definition is a member-specification.

This is possibly related to bug 70077.

For comparison Clang rejects, but MSVC accepts.

[Bug c++/114764] noexcept on a friend complains about incomplete type

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114764

--- Comment #1 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
EDG also accepts it ...

[Bug c++/114764] noexcept on a friend complains about incomplete type

[mpolacek at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114764

Marek Polacek <mpolacek at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |mpolacek at gcc dot gnu.org

--- Comment #2 from Marek Polacek <mpolacek at gcc dot gnu.org> ---
I think I remember discussing this on the Core list.  IIRC the trouble was that
friend decls can be redeclared and that made it quite hard to implement right. 
So the current behavior seems OK, and perhaps the standard should change.

[Bug c++/114764] noexcept on a friend complains about incomplete type

[dangelog at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114764

--- Comment #3 from Giuseppe D'Angelo <dangelog at gmail dot com> ---
I guess you're referring to https://lists.isocpp.org/core/2019/07/6785.php ?

I'm really not sure why a friend function declaration is different from a free
function, where multiple equivalent declarations are allowed?

Btw, the "real" case was a definition of a friend (hidden friend). Could at
least that be supported?

[Bug c++/114764] noexcept on a friend complains about incomplete type

[mpolacek at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114764

--- Comment #4 from Marek Polacek <mpolacek at gcc dot gnu.org> ---
I don't think so, it's the same problem.  You could have

struct S {
  friend void f() noexcept(noexcept(a));
  friend void f() noexcept(noexcept(b)) { }
  int a;
  int b;
};

and we'd have to track if the exception specifications match.

[Bug c++/114764] noexcept on a friend complains about incomplete type

[dangelog at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114764

--- Comment #5 from Giuseppe D'Angelo <dangelog at gmail dot com> ---
Just to understand, are we talking about an implementation challenge (because
within a class you may refer to stuff not yet declared when parsing the
noexcept spec, or similar), or that using noexcept on a friend "doesn't make
sense"?

[Bug c++/114764] noexcept on a friend complains about incomplete type

[mpolacek at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114764

--- Comment #6 from Marek Polacek <mpolacek at gcc dot gnu.org> ---
The former: I'd have to introduce checking that tracks all the declarations and
checks that their noexcept-specs match after delayed parsing has taken place. 
It's not impossible but I didn't (and still don't) think that it's something
worth doing.  Sorry.

[Bug c++/114764] noexcept on a friend complains about incomplete type

[dangelog at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114764

--- Comment #7 from Giuseppe D'Angelo <dangelog at gmail dot com> ---
I get it :)

If you wanted an actual use-case (rather than a synthetic testcase), we
stumbled upon this bug from implementing a friend operator==:


```
class S {

  bool comparesEqual(S, S) noexcept; // pass by value, object is
small/trivially copyable
  friend inline bool operator==(S a, S b) noexcept(noexcept(comparesEqual(S,
S))) {
     returns comparesEqual(a, b);
  }
};
```

which is the result of some macro expansions through which we support C++20's
comparisons in C++17 in Qt. The problem is the pass by value -- changing it to
pass by const-ref fixes it, but generates different linting about not passing a
small TC object by value...