[Bug c++/113117] New: ambiguous call during operator overloading is not detected for templates

[Bug c++/113117] New: ambiguous call during operator overloading is not detected for templates

[armagvvg at gmail dot com]

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

            Bug ID: 113117
           Summary: ambiguous call during operator overloading is not
                    detected for templates
           Product: gcc
           Version: 13.2.1
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: armagvvg at gmail dot com
  Target Milestone: ---

In a nutshell: the next code snippet is compiled successfully, but shouldn't be
according to a language standard:

struct S {
    template <class T>
    S& operator<<(T) { return *this; }
};

template <class T>
T& operator<<(T& s, int) { return s; }

int main () {
    S s;
    s << 1;
}

Details:

Operator overloading for classes can be implemented with free functions and
with class member. When both exist, the C++ standard (I used C++17, part 16.5.2
- Overloaded Operators -> Binary operators) says that "If both forms of the
operator function have been declared, the rules in 16.3.1.2 determine which, if
any, interpretation is used.". The set of candidates contains both the member
and the free function then. The member is considered as a free function with
first implicit parameter (16.3.1 - Candidate functions and argument lists) - "a
member function is considered to have an extra parameter, called the implicit
object parameter, which represents the object for which the member function has
been called".

Thus we have two templates here:
1. template <class T> T& operator<<(T&, int) - defined in the code
2. template <class T> S& operator<<(S, T) - synthesized from the member
function

16.3.3 "Best viable function" mentions that "F1 and F2 are function template
specializations, and the function template for F1 is more specialized than the
template for F2 according to the partial ordering rules described in
17.5.6.2...". But no one template is more specialized for a call "operator<<(S,
int)". Thus we have two best viable functions and "If there is exactly one
viable function that is a better function than all other viable functions, then
it is the
one selected by overload resolution; otherwise the call is ill-formed".

This code snippet should be ill-formed. But it doesn't.

clang detects this as an error.

[Bug c++/113117] ambiguous call during operator overloading is not detected for templates

[pinskia at gcc dot gnu.org]

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

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |accepts-invalid,
                   |                            |needs-bisection

--- Comment #1 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
This seems to be fixed on the trunk.

[Bug c++/113117] ambiguous call during operator overloading is not detected for templates

[armagvvg at gmail dot com]

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

--- Comment #2 from Vyacheslav Grigoryev <armagvvg at gmail dot com> ---
Looks so, checking on https://godbolt.org/z/vb6s6cY6Y. Hm... wasting a time on
filling the bug :(

[Bug c++/113117] ambiguous call during operator overloading is not detected for templates

[ppalka at gcc dot gnu.org]

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

Patrick Palka <ppalka at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|---                         |DUPLICATE
                 CC|                            |ppalka at gcc dot gnu.org
             Status|UNCONFIRMED                 |RESOLVED

--- Comment #3 from Patrick Palka <ppalka at gcc dot gnu.org> ---
Recently fixed on trunk by r14-6221-gc1e54c82a9e185, and indeed this seems
pretty much a dup of PR53499.  Thanks for the detailed bug report nonetheless

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