aboutsummaryrefslogtreecommitdiff
path: root/gcc/expr.cc
diff options
context:
space:
mode:
authorJason Merrill <jason@redhat.com>2023-05-26 12:28:15 -0400
committerJason Merrill <jason@redhat.com>2023-06-02 11:46:21 -0400
commit9872d56661ade358c440914361c1ebdccd975bec (patch)
treedb89d08f2d8fbfe8aa4ba1892999b6a25e25be04 /gcc/expr.cc
parent957798e44e7194f7b6a67b19f85ff72eab9a0d0e (diff)
downloadgcc-9872d56661ade358c440914361c1ebdccd975bec.zip
gcc-9872d56661ade358c440914361c1ebdccd975bec.tar.gz
gcc-9872d56661ade358c440914361c1ebdccd975bec.tar.bz2
c++: fix explicit/copy problem [PR109247]
In the testcase, the user wants the assignment to use the operator= declared in the class, but because [over.match.list] says that explicit constructors are also considered for list-initialization, as affirmed in CWG1228, we end up choosing the implicitly-declared copy assignment operator, using the explicit constructor template for the argument, which is ill-formed. Other implementations haven't implemented CWG1228, so we keep getting bug reports. Discussion in CWG led to the idea for this targeted relaxation: if we use an explicit constructor for the conversion to the argument of a copy or move special member function, that makes the candidate worse than another. DR 2735 PR c++/109247 gcc/cp/ChangeLog: * call.cc (sfk_copy_or_move): New. (joust): Add tiebreaker for explicit conv and copy ctor. gcc/testsuite/ChangeLog: * g++.dg/cpp0x/initlist-explicit3.C: New test.
Diffstat (limited to 'gcc/expr.cc')
0 files changed, 0 insertions, 0 deletions