I think the first approach makes more sense from a pragmatic point of view. The semantics of the return stmt 'return A();' has 3 parts: <div>1. construct temp object A().</div><div>2. copy the object into the return value slot.</div>
<div>3. destruct A().</div><div>Since in the analyzer the CFG is linearized, we have to no way to know that the temp object A() should be copied into the return value slot (whatever this means for the analysis engine) until we see the ReturnStmt. But if the dtor is put before the ReturnStmt, the temp object is already destructed when we want to return it.</div>
<div><br></div><div>So the ReturnStmt is the indicator that the returned value should be prepared. We should not destruct the object before that.</div><div><br></div><div>Plus, the ReturnStmt is not handled as block terminator in the CFG builder currently. It is only treated as a normal block element.<br>
<br><div class="gmail_quote">On Tue, Jan 17, 2012 at 1:29 PM, Ted Kremenek <span dir="ltr"><<a href="mailto:kremenek@apple.com">kremenek@apple.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

                <div>
                    <div>Hi Erik,</div><div><br></div><div>Thanks for working on this.  I've commented in the PR.</div><div><br></div><div>My concern is that I am having second thoughts about whether or not this is the right direction.  If there are temporaries in the return expression, should those destructors appear before the 'return' statement (but after the subexpression of 'return' gets evaluated)?  I can see it both ways.</div>
<div><br></div><div>For example:</div><div><br></div><div>  return A();</div><div><br></div><div>where 'A' converts to whatever the return value type should be, and ~A() is non-trivial.  Technically, ~A() evaluates after the enclosing statement.  We're giving 'return' special treatment in your patch.</div>
<div><br></div><div>One clean representation of this is to put all the destructors after the 'return' in the CFGBlock.  The other way is to have the destructors appear after the subexpression of 'return', but before the 'return' itself.  The former requires clients of the CFG to rethink where they expect 'return' to be in a CFGBlock.</div>
<div><br></div><div>What do you think?</div><div><br></div><div>Ted</div>
                </div>
                <div></div>
                 
                <p style="color:#a0a0a8">On Thursday, January 12, 2012 at 6:30 AM, Erik Verbruggen wrote:</p>
                <blockquote type="cite" style="border-left-style:solid;border-width:1px;margin-left:0px;padding-left:10px">
                    <span><div><div><div>Hello,</div><div><br></div><div>Attached is a patch for one of the things mentioned in PR 11645, which </div><div>is that in the CFG the destructor calls end up after the return statement.</div>
<div><br></div><div>-- Erik.</div></div></div></span>
                 
                 
                <div style="border-bottom:1px solid #f0f0f0;min-height:10px">
                </div>
                <br>
                 
                <div style="font-weight:bold;font-size:14px;margin-bottom:5px">Attachments:</div>
                 
                 
                 
                 
                 
                 
                 
                <div>
                     
                    <div>- 0001-CFG-Partial-fix-for-PR-11645-put-destructor-calls-be.patch</div>
                     
                </div>
                 
                 
                 
                </blockquote>
                 
                <div>
                    <br>
                </div>
</blockquote></div><br></div>