Bug 94141 - c++20 rewritten operator== recursive call mixing friend and external operators for template class
Summary: c++20 rewritten operator== recursive call mixing friend and external operator...
Status: SUSPENDED
Alias: None
Product: gcc
Classification: Unclassified
Component: c++ (show other bugs)
Version: 10.0
: P3 normal
Target Milestone: ---
Assignee: Not yet assigned to anyone
URL:
Keywords: wrong-code
Depends on:
Blocks: c++-friends, cxxfriends
  Show dependency treegraph
 
Reported: 2020-03-11 13:51 UTC by Marc Glisse
Modified: 2024-03-25 23:52 UTC (History)
4 users (show)

See Also:
Host:
Target:
Build:
Known to work:
Known to fail:
Last reconfirmed: 2021-08-04 00:00:00


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Marc Glisse 2020-03-11 13:51:07 UTC
(reduced from a user of boost/operators.hpp)

template <typename> class A;
template <typename T> bool operator==(const A<T>&, int) { return false; }

template <typename> class A {
  friend bool operator==(int y, const A& x) { return x == y; }
};

int main(){
  A<short> q;
  q==3;
  3==q;
}

$ g++ -std=c++2a a.c -Wall && ./a.out
a.c: In instantiation of 'bool operator==(int, const A<short int>&)':
a.c:10:6:   required from here
a.c:5:56: warning: in C++20 this comparison calls the current function recursively with reversed arguments
    5 |   friend bool operator==(int y, const A& x) { return x == y; }
      |                                                      ~~^~~~
zsh: segmentation fault  ./a.out

If I make both operators friends, or move both outside, gcc is happy, but in this mixed case, it doesn't seem to want to use the first operator== and prefers the rewritten second operator==. Of course removing the second operator== completely also works.
Clang is fine with this version of the code.

I have trouble parsing the standard wording, but IIRC one of the principles when adding <=> was that explicitly written functions should have priority over new, invented ones.

Bug 93807 is the closest I could find.
Comment 1 Marc Glisse 2020-04-05 14:00:26 UTC
It looks like clang-10+ also generates an infinite loop on this code. Does the standard really give priority to some implicit function over a user-defined one that is an exact match?
Comment 2 Marc Glisse 2020-04-05 16:48:37 UTC
Ah, maybe the friend function is not quite a template, so the generated swapped function is not a template either, and thus it has priority over a template if both are exact matches?

This is going to break a number of users of boost/operators.hpp, and possibly other mixins using a similar technique.
Comment 3 Marc Glisse 2020-05-21 09:12:35 UTC
It seems that this is as currently specified in C++20, but that some people are going to try and change the rules to avoid breaking code like this.
Comment 4 Laurent Rineau 2020-05-21 09:53:02 UTC
(In reply to Marc Glisse from comment #3)
> It seems that this is as currently specified in C++20, but that some people
> are going to try and change the rules to avoid breaking code like this.

Do you have reference to the discussion on the subject?
Comment 5 Andrew Pinski 2021-08-04 17:46:05 UTC
(In reply to Marc Glisse from comment #1)
> It looks like clang-10+ also generates an infinite loop on this code.

clang 12+ now does not produce an infinite loop.

GCC trunk still does though.