[Bug c++/113529] Incorrect result of requires-expression in case of function call ambiguity and `operator<=>`
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113529 Patrick Palka changed: What|Removed |Added Target Milestone|--- |13.3 Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #4 from Patrick Palka --- Fixed for GCC 13.3 / 14.
[Bug c++/113529] Incorrect result of requires-expression in case of function call ambiguity and `operator<=>`
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113529 --- Comment #3 from GCC Commits --- The releases/gcc-13 branch has been updated by Patrick Palka : https://gcc.gnu.org/g:663d9e168bc1f2649721436f5188563eda9d04f0 commit r13-8255-g663d9e168bc1f2649721436f5188563eda9d04f0 Author: Patrick Palka 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 (cherry picked from commit fecb45a936d62ca24dd8b4985ea0555c28edefa8)
[Bug c++/113529] Incorrect result of requires-expression in case of function call ambiguity and `operator<=>`
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113529 --- Comment #2 from GCC Commits --- The master branch has been updated by Patrick Palka : https://gcc.gnu.org/g:fecb45a936d62ca24dd8b4985ea0555c28edefa8 commit r14-8402-gfecb45a936d62ca24dd8b4985ea0555c28edefa8 Author: Patrick Palka 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
[Bug c++/113529] Incorrect result of requires-expression in case of function call ambiguity and `operator<=>`
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113529 Patrick Palka 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<=>`
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113529 Andrew Pinski 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 --- 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.
