[cfe-commits] [Review] Partial fix for PR 11645: put destructor calls before a return statement.

[Chandler Carruth]

On Tue, Jan 17, 2012 at 8:22 AM, Erik Verbruggen <erik.verbruggen at me.com>wrote:

>
>  I think the C++ standard* provides some help in making a choice about
>> how to represent this. It doesn't actually say that ~A() evaluates after
>> the enclosing statement. Instead it defines 'full-expressions' as an
>> expression which is not a subexpression of any other expression
>> ([intro.execution] 1.9p10). As *part* of this full-expression, all
>> temporary objects' non-trivial destructors must be called
>> ([class.temporary] 12.2p3). To me, that indicates that the destructor
>> should be placed after the complete subexpression in the return
>> statement, but within the return statement itself. This has the nice
>> property of preserving the (very useful!) invariant that terminator
>> statements are the last statement in the CFG block.
>>
>
> This would mean that a full expression of "return SomeClass();" would get
> split in two:


A fine point, but an important one: "return SomeClass();" is not a full
expression. It is a statement. The only full expression here is
"SomeClass();". I think it is very natural to handle the full expression
evaluation prior to handling the statement in the CFG.


> all the implicit destructors calls for the scope get placed between the
> return value calculation and the actual return of that value. If you would
> want to base code generation on the CFG, it would force an extra pass to
> identify whether calculated values should be constructed in a return value
> slot or not. So I think that using return/throw (and possibly goto) as
> markers, would be a simplification.


I think we should cross this bridge when we get there. I strongly suspect
that there are easy ways to solve the return value slot question no matter
what representation we choose, and we should choose the representation of
the CFG based on the language standard and the tightest model possible for
the semantics specified there.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20120117/65f86ae5/attachment.html>