diff options
author | Jason Merrill <jason@redhat.com> | 2023-05-26 12:28:15 -0400 |
---|---|---|
committer | Jason Merrill <jason@redhat.com> | 2023-06-02 11:46:21 -0400 |
commit | 9872d56661ade358c440914361c1ebdccd975bec (patch) | |
tree | db89d08f2d8fbfe8aa4ba1892999b6a25e25be04 /gcc/expr.cc | |
parent | 957798e44e7194f7b6a67b19f85ff72eab9a0d0e (diff) | |
download | gcc-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