[cfe-commits] r155218 - in /cfe/trunk: include/clang/Sema/Sema.h lib/Sema/SemaDeclCXX.cpp lib/Sema/SemaLookup.cpp test/CXX/special/class.copy/implicit-move.cpp test/CXX/special/class.copy/p8-cxx11.cpp

Richard Smith richard at metafoo.co.uk
Fri Apr 20 16:27:44 PDT 2012


On Fri, Apr 20, 2012 at 2:35 PM, Eli Friedman <eli.friedman at gmail.com>wrote:

> On Fri, Apr 20, 2012 at 11:46 AM, Richard Smith
> <richard-llvm at metafoo.co.uk> wrote:
> > Author: rsmith
> > Date: Fri Apr 20 13:46:14 2012
> > New Revision: 155218
> >
> > URL: http://llvm.org/viewvc/llvm-project?rev=155218&view=rev
> > Log:
> > Fix bug where a class's (deleted) copy constructor would be implicitly
> given a
> > non-const reference parameter type if the class had any subobjects with
> deleted
> > copy constructors. This causes a rejects-valid if the class's copy
> constructor
> > is explicitly defaulted (as happens for some implementations of
> std::pair etc).
>
> Is this the same issue as http://llvm.org/bugs/show_bug.cgi?id=12575 ?


Yes, thanks.


> > +struct DeletedNonConstCopy {
> > +  DeletedNonConstCopy(DeletedNonConstCopy &) = delete;
> > +};
>
[...]

> > +struct E : DeletedNonConstCopy {};
>
[...]

> > +  friend E::E(E &);
>
> I'm not sure I understand the reasoning for E; why shouldn't it be
> E::E(const E&)?  DeletedConstCopy and DeletedNonConstCopy are the same
> in the sense that neither can be copy-constructed from a const object.


Quoth the standard ([class.copy] p8):

"The implicitly-declared copy constructor for a class X will have the form
X::X(const X&)
if
— each direct or virtual base class B of X has a copy constructor whose
first parameter is of type const
B& or const volatile B&, and
— for all the non-static data members of X that are of a class type M (or
array thereof), each such class
type has a copy constructor whose first parameter is of type const M& or
const volatile M&.119
Otherwise, the implicitly-declared copy constructor will have the form
X::X(X&)"

DeletedNonConstCopy does not have a copy constructor whose first parameter
is of type 'const DeletedNonConstCopy&'.

FWIW, I find it very strange that we are required to issue a diagnostic if
a defaulted constructor has the wrong argument type, even if it would have
been defined as deleted anyway.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20120420/a0e160d6/attachment.html>


More information about the cfe-commits mailing list