r243463 - Do not give a -Wredundant-move warning when removing the move will result in an

[Richard Smith]

On Wed, Jul 29, 2015 at 11:51 AM, Arthur O'Dwyer <arthur.j.odwyer at gmail.com>
wrote:

> When the criteria for elision of a copy operation are met[,] *or would be
> met save for the fact that the source object is a function parameter,*
> and the object to be copied is designated by an lvalue, overload resolution
> to select the constructor for the copy is first performed as if the object
> were designated by an rvalue. If overload resolution fails, or if the type
> of the first parameter of the selected constructor is not an rvalue
> reference to the object’s type (possibly cv-qualified), overload resolution
> is performed again, considering the object as an lvalue.  —N3797, 12.8
> [class.copy]/32
>
>
> N4296 says the same thing, but much more verbosely:
>
> When the criteria for elision of a copy/move operation are met, but not
> for an exception-declaration, and the object to be copied is designated
> by an lvalue, or when the expression in a return statement is a (possibly
> parenthesized) id-expression that names an object with automatic storage
> duration declared in the body or parameter-declaration-clause of the
> innermost enclosing function or lambda-expression, overload resolution to
> select the constructor for the copy is first performed as if the object
> were designated by an rvalue.
>  Looks to me as if GCC is correct and Clang is (/has always been)
> incorrect.
>

No, the conditions for copy elision include that the source and destination
type are the same (up to cv qualification), so the old and new rules are
quite different. This is
http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#1579, which
Clang does not yet implement.


> –Arthur
>
>
> On Wed, Jul 29, 2015 at 2:57 AM, Sebastian Redl <
> sebastian.redl at getdesigned.at> wrote:
>
>>
>>
>> On 28.07.2015 21:06, Richard Trieu wrote:
>>
>>> Author: rtrieu
>>> Date: Tue Jul 28 14:06:16 2015
>>> New Revision: 243463
>>>
>>> URL: http://llvm.org/viewvc/llvm-project?rev=243463&view=rev
>>> <https://urldefense.proofpoint.com/v2/url?u=http-3A__llvm.org_viewvc_llvm-2Dproject-3Frev-3D243463-26view-3Drev&d=AwMFaQ&c=8hUWFZcy2Z-Za5rBPlktOQ&r=BSqEv9KvKMW_Ob8SyngJ70KdZISM_ASROnREeq0cCxk&m=_L10PmZrnBYWPkOd1zjulZ_AU7nSHXR5hcD-EeR36K0&s=7I1ON7EyKTaZa2RuYMve8B75NKVHPYcIDAGzSs_Qlik&e=>
>>> Log:
>>> Do not give a -Wredundant-move warning when removing the move will
>>> result in an
>>> error.
>>>
>>> If the object being moved has a move constructor and a deleted copy
>>> constructor,
>>> std::move is required, otherwise Clang will give a deleted constructor
>>> error.
>>>
>>>  Is that actually correct behavior by Clang? GCC 5.2 compiles the
>> following without problems:
>>
>> struct A {
>>     A() {}
>>     A(A&&) {}
>> };
>>
>> struct B {
>>   B(A) {}
>> };
>>
>> B fn(A a) {
>>     return a;
>> }
>>
>> int main() {
>>     fn(A());
>> }
>>
>> Sebastian
>> _______________________________________________
>> cfe-commits mailing list
>> cfe-commits at cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
>>
>
>
> _______________________________________________
> cfe-commits mailing list
> cfe-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20150729/c0ee285d/attachment.html>