[cfe-commits] r143399 - in /cfe/trunk: lib/CodeGen/CGBlocks.cpp lib/CodeGen/CGExpr.cpp test/CodeGenCXX/block-rvalue-reference-capture.cpp

[Richard Smith]

On Wed, November 2, 2011 16:02, Sebastian Redl wrote:
> On 02.11.2011 16:55, jahanian wrote:
>> On Nov 2, 2011, at 7:59 AM, Douglas Gregor wrote:
>>> On Nov 2, 2011, at 1:33 AM, John McCall wrote:
>>>> On Oct 31, 2011, at 4:44 PM, Fariborz Jahanian wrote:
>>>>> Author: fjahanian
>>>>> Date: Mon Oct 31 18:44:33 2011
>>>>> New Revision: 143399
>>>>>
>>>>>
>>>>> URL: http://llvm.org/viewvc/llvm-project?rev=143399&view=rev
>>>>> Log:
>>>>> Adds IRGen support for captured rvalue references in blocks.
>>>>> In this case, temporary value is copied into block descriptor
>>>>> as their own copy to work on. // rdar://9971124
>>>> Sorry for missing this earlier, but I really don't think is the right
>>>> thing to do.  Block captures of l-value references capture a reference;
>>>> making block captures of r-value references capture a copy is bizarrely
>>>> inconsistent.
>>>
>>> What do you propose? Capture the reference, even though it's almost
>>> surely going to refer to a temporary?
>> In the absence of any precedence of how to treat rvalue reference in code
>> gen. A compromise may be to make the copy as is currently done, but
>> establish a reference to it on entry to the block. In essence, temporary is
>> moved to the block descriptor. But I am not sure if this will make any
>> difference in terms of semantics of such references.
>>
> What are the semantics of rvalue references captured by C++11 lambdas?
> Even if there is no intuitive handling of the situation, following C++11
> lambdas would at least have the advantage of not having two *different*
> surprising behaviors. (Or do C++'s explicit captures make the question moot?)

Inside lambdas, for a capture-by-copy of a reference to non-function type, a
temporary is created for both kinds of reference (and the value is copied, not
moved, into it in both cases). For a capture-by-reference, the name within the
closure simply refers to the variable in the outer scope (there is no mandated
implicit reference member, but that's a valid implementation strategy).

The C++11 semantics generally are that *named* entities of rvalue reference
types behave like lvalue references almost everywhere; it would seem strange
to me if this behavior varied inside an ObjC block. But a huge pile of salt:
I've never written a single line of ObjC, let alone ObjC++11 :)

Richard