[Bug c++/113529] New: Incorrect result of requires-expression in case of function call ambiguity

[Bug c++/113529] New: Incorrect result of requires-expression in case of function call ambiguity

[fchelnokov at gmail dot com]

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

            Bug ID: 113529
           Summary: Incorrect result of requires-expression in case of
                    function call ambiguity
           Product: gcc
           Version: 13.2.1
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: fchelnokov at gmail dot com
  Target Milestone: ---

In this program


#include <compare>

struct A { 
    auto operator <=>(const A&) const = default;
    bool operator <(const A&) const = default;
};
struct B { 
    auto operator <=>(const B&) const = default; 
};
struct C : A, B {};

template<typename T>
concept Cmp = requires(T u, T v) { u < v; };

//auto cmp = C{} < C{}; //this correctly fails due to ambiguity
static_assert( !Cmp<C> ); //but this evaluates wrongly in GCC


C{} < C{} is correctly rejected as ambiguous, but for some reason `requires` in
GCC returns that the objects can be compared. This program is accepted by Clang
truck (to be v18). Online demo: https://godbolt.org/z/76zoYMd6h

Explanation of ambiguity: https://stackoverflow.com/a/69245639/7325599

[Bug c++/113529] Incorrect result of requires-expression in case of function call ambiguity and `operator<=>`

[pinskia at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|Incorrect result of         |Incorrect result of
                   |requires-expression in case |requires-expression in case
                   |of function call ambiguity  |of function call ambiguity
                   |                            |and `operator<=>`
   Last reconfirmed|                            |2024-01-21
           Keywords|                            |wrong-code
             Status|UNCONFIRMED                 |NEW
     Ever confirmed|0                           |1

--- Comment #1 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Confirmed.

I just tried a normal function and not operator<=> and GCC does the correct
thing.

It is definitely `operator<=>` related because removing `operator<=>` and
having an ambigous `operator<` does the correct thing too.

[Bug c++/113529] Incorrect result of requires-expression in case of function call ambiguity and `operator<=>`

[ppalka at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Assignee|unassigned at gcc dot gnu.org      |ppalka at gcc dot gnu.org
                 CC|                            |ppalka at gcc dot gnu.org
             Status|NEW                         |ASSIGNED

[Bug c++/113529] Incorrect result of requires-expression in case of function call ambiguity and `operator<=>`

[cvs-commit at gcc dot gnu.org]

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

--- Comment #2 from GCC Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Patrick Palka <ppalka@gcc.gnu.org>:

https://gcc.gnu.org/g:fecb45a936d62ca24dd8b4985ea0555c28edefa8

commit r14-8402-gfecb45a936d62ca24dd8b4985ea0555c28edefa8
Author: Patrick Palka <ppalka@redhat.com>
Date:   Wed Jan 24 17:11:09 2024 -0500

    c++: ambiguous member lookup for rewritten cands [PR113529]

    Here we handle the operator expression u < v inconsistently: in a SFINAE
    context we accept it, and in a non-SFINAE context we reject it with

      error: request for member 'operator<=>' is ambiguous

    as per [class.member.lookup]/6.  This inconsistency is ultimately
    because we neglect to propagate error_mark_node after recursing in
    add_operator_candidates, fixed like so.

            PR c++/113529

    gcc/cp/ChangeLog:

            * call.cc (add_operator_candidates): Propagate error_mark_node
            result after recursing to find rewritten candidates.

    gcc/testsuite/ChangeLog:

            * g++.dg/cpp2a/spaceship-sfinae3.C: New test.

    Reviewed-by: Jason Merrill <jason@redhat.com>

[Bug c++/113529] Incorrect result of requires-expression in case of function call ambiguity and `operator<=>`

[cvs-commit at gcc dot gnu.org]

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

--- Comment #3 from GCC Commits <cvs-commit at gcc dot gnu.org> ---
The releases/gcc-13 branch has been updated by Patrick Palka
<ppalka@gcc.gnu.org>:

https://gcc.gnu.org/g:663d9e168bc1f2649721436f5188563eda9d04f0

commit r13-8255-g663d9e168bc1f2649721436f5188563eda9d04f0
Author: Patrick Palka <ppalka@redhat.com>
Date:   Wed Jan 24 17:11:09 2024 -0500

    c++: ambiguous member lookup for rewritten cands [PR113529]

    Here we handle the operator expression u < v inconsistently: in a SFINAE
    context we accept it, and in a non-SFINAE context we reject it with

      error: request for member 'operator<=>' is ambiguous

    as per [class.member.lookup]/6.  This inconsistency is ultimately
    because we neglect to propagate error_mark_node after recursing in
    add_operator_candidates, fixed like so.

            PR c++/113529

    gcc/cp/ChangeLog:

            * call.cc (add_operator_candidates): Propagate error_mark_node
            result after recursing to find rewritten candidates.

    gcc/testsuite/ChangeLog:

            * g++.dg/cpp2a/spaceship-sfinae3.C: New test.

    Reviewed-by: Jason Merrill <jason@redhat.com>
    (cherry picked from commit fecb45a936d62ca24dd8b4985ea0555c28edefa8)

[Bug c++/113529] Incorrect result of requires-expression in case of function call ambiguity and `operator<=>`

[ppalka at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|---                         |13.3
             Status|ASSIGNED                    |RESOLVED
         Resolution|---                         |FIXED

--- Comment #4 from Patrick Palka <ppalka at gcc dot gnu.org> ---
Fixed for GCC 13.3 / 14.