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

[Stephen Lin]

> Whoops! Never mind, I realized this test is incorrect since it's
> calling a deleting destructor and the first check is checking the
> constructor not the destructor. I will look into it and get back to
> you.

OK, sorry for the noise: it turns out the last patch I sent it doing
the right thing, but largely be accident: it's not attaching
'returned' to the call site and only at the declaration/definition, so
only direct calls end up using the 'returned' attribute, which is what
we want.

But this is actually because EmitCall treats the call as
void-returning even when it returns 'this', because the return value
is gets is based on semantic ReturnValueSlot rather than from the
ABI-provided constructor signature, so ConstructAttributeList is
called with a 'this'-return when constructing a declaration/definition
but a 'void' return when constructing a call site. I'm surprised this
doesn't trigger any asserts, actually...

Anyway, since this is not behavior that should be relied upon (and
maybe should be fixed at some point, too), I fixed it so that
'returned' is applied by SetFunctionAttributes(), which is only
applied to declarations/definitions rather than call sites and takes a
GlobalDecl already. So this is probably the minimal impact method of
implementing this.

Thanks for bringing up the thunk issue; would not have realized what
was going on otherwise. Please let me know if you have any more
suggestions or comments.

-Stephen
-------------- next part --------------
A non-text attachment was scrubbed...
Name: this-return1.patch
Type: application/octet-stream
Size: 16483 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20130503/978e7779/attachment.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: this-return2.patch
Type: application/octet-stream
Size: 25924 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20130503/978e7779/attachment-0001.obj>