[PATCH] Have 'this'-returning constructors and destructors to take advantage of the new backend 'returned' attribute

[Stephen Lin]

I actually just did that to make it consistent with the EmitVirtualDestructorCall signature because I assumed that was what it was like originally. I can remove the argument and return void instead though.

Is there any point to EmitVirtualDestructorCall taking a ReturnValueSlot and returning a return value? One of the two places EmitVirtualDestructorCall is called is EmitCXXMemberCall, which passes it a ReturnValueSlot and has an RValue; if there no valid use call for that ReturnValueSlot being non-empty should I change EmitCXXMemberCall to assert that and return RValue::get(0) instead, in that branch?

No real reason for separating the patches, just thought it would be easier to review that way since they're basically disjoint and I had them as separate commits locally anyway. I can submit them to svn as one patch.

-Stephen

On Jun 4, 2013, at 6:15 PM, John McCall <rjmccall at apple.com> wrote:

> On Jun 3, 2013, at 8:11 PM, Stephen Lin <swlin at apple.com> wrote:
>> Here's a freshly rebased pair of patches.
>> <this-return1.patch><this-return2.patch>
> 
> I don't understand why EmitConstructorCall needs to take a ReturnValueSlot or return an RValue.  There's one call site, and it passes an empty ReturnValueSlot and ignores the result. This seems to just be cluttering the API.
> 
> Is there a reason why these patches are separated?  (Did I ask for that for some reason?)
> 
> John.