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

2024-04-20 Thread dangelog at gmail dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114764

--- Comment #7 from Giuseppe D'Angelo  ---
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...

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

2024-04-19 Thread mpolacek at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114764

--- Comment #6 from Marek Polacek  ---
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

2024-04-19 Thread dangelog at gmail dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114764

--- Comment #5 from Giuseppe D'Angelo  ---
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

2024-04-18 Thread mpolacek at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114764

--- Comment #4 from Marek Polacek  ---
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

2024-04-18 Thread dangelog at gmail dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114764

--- Comment #3 from Giuseppe D'Angelo  ---
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

2024-04-18 Thread mpolacek at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114764

Marek Polacek  changed:

   What|Removed |Added

 CC||mpolacek at gcc dot gnu.org

--- Comment #2 from Marek Polacek  ---
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

2024-04-18 Thread pinskia at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114764

--- Comment #1 from Andrew Pinski  ---
EDG also accepts it ...