[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

[Eli Friedman]

On Fri, Apr 20, 2012 at 4:27 PM, Richard Smith <richard at metafoo.co.uk> wrote:
> 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.

Yes... maybe worth a DR?

-Eli