[cfe-commits] r104422 - in /cfe/trunk/lib/CodeGen: CGExprAgg.cpp CGObjC.cpp CGObjCGNU.cpp CGObjCMac.cpp CGObjCRuntime.h CodeGenFunction.h

[John McCall]

On May 23, 2010, at 11:24 AM, Douglas Gregor wrote:

> 
> On May 23, 2010, at 10:38 AM, Fariborz Jahanian wrote:
> 
>> 
>> On May 22, 2010, at 3:18 PM, John McCall wrote:
>> 
>>> On May 22, 2010, at 9:13 AM, Fariborz Jahanian wrote:
>>>> Wouldn't removing call to EmitFinalDestCopy change things in this  
>>>> patch? This routine deals with GC API, as well as copying result to  
>>>> DestPtr.
>>> 
>>> Ugh, you're right.  I believe I've restored the old behavior in a  
>>> way that doesn't interfere with return-value behavior in C++.
>>> 
>>> I have no idea how to reconcile the GC API with C++;  we'll have to  
>>> talk about this.
>> 
>> Thanks. This was  my main concern.  This particular API was not being  
>> invoked for ObjC++ case, my concern was
>> changing behavior for ObjC.
> 
> 
> Perhaps we should use the GC API for a separate copy only when dealing with POD types? Then we're only missing the GC calls for C++ types w/ interesting special member functions.

The test I implemented was "a record type with a trivial copy constructor and a trivial destructor and which satisfies hasObjectMember()".  The trivial copy constructor check will need to change for C++0x, but so will every call to hasTrivialCopyConstructor(), I think.

Is there a document about the GC API anywhere?  I'm sure it doesn't really consider ObjC++ at all, but I'd like to review the requirements anyway, just to see whether there's any earthly way we can support them in C++.

John.