[PATCH] Proposal on how to fix temporary dtors.

Manuel Klimek klimek at google.com
Mon Jun 23 12:44:43 PDT 2014

Just in case I misinterpreted something: I'm waiting for a final LG (or
!LG) ...

On Fri, Jun 20, 2014 at 7:02 AM, Manuel Klimek <klimek at google.com> wrote:

> On Fri, Jun 20, 2014 at 5:28 AM, Jordan Rose <jordan_rose at apple.com>
> wrote:
>> On Jun 19, 2014, at 14:19 , Manuel Klimek <klimek at google.com> wrote:
>> On Thu, Jun 19, 2014 at 6:30 PM, Jordan Rose <jordan_rose at apple.com>
>> wrote:
>>> I think the algorithm makes sense. I'm not sure it's different, though,
>>> than just passing up the first (or last) CXXBindTemporaryExpr visited for a
>>> given expression, which would look like this:
>>>     // For a logical expression...
>>>     VisitForTemporaryDtors(E->getLHS(), false, &LastBTE);
>>>     const CXXBindTemporaryExpr *InnerBTE = nullptr;
>>>     VisitForTemporaryDtors(E->getRHS(), false, &InnerBTE);
>>>     InsertTempDtorDecisionBlock(InnerBTE);
>>> Are there any cases that wouldn't cover?
>> Well, the problem is what to do if we don't have a BTE yet; if we only
>> wanted to pass one pointer, the semantics on function exit would need to be:
>> if (BTE) { we have already found a BTE, no need to insert a new block
>> when we encounter the next }
>> else { we have not yet found a BTE, so we need to insert a new block when
>> we find one }
>> The "unconditional" branch would only fit with the first part, so we
>> would need to somehow conjure non-null BTE for all unconditional entries,
>> and then afterwards know that this is a special value, because since we
>> didn't add an extra block (as we were running an unconditional case), we
>> don't need a decision block.
>> I'd say that's a pretty strong argument that we at least need to pass the
>> CXXBindTemporaryExpr* and a bool IsConditional.
>> Now it's right that we don't need to remember the Succ when we hit the
>> conditional, and instead we could just always store the Succ when we enter
>> a recursive visitation for a conditional branch (we need to store the Succ
>> because we can have nested conditionals), but that seems to me like it
>> would distribute the logic through even more places, and thus undesirable.
>> My observation is that only certain expressions cause conditional
>> branching, and that for these expressions you *always* need to introduce
>> a new block if you find any destructors, say, in the RHS of a logical
>> expression. So
>> 1. if you're in a non-conditional sub-expression, it doesn't matter
>> whether there are temporaries or not; you don't need to insert a decision
>> branch,
>> 2. if you're in a conditional sub-expression and there are no
>> temporaries, you don't need to insert a decision branch,
>> 3. if you're in a conditional sub-expression and there are temporaries,
>> you can use any temporary from that subexpression as the guard.
> That is exactly the algorithm.
>> So it looks to me like the only information you have to pass up from
>> traversing the sub-expressions is a BTE from that subexpression. Everything
>> else can be handled at the point where you start processing that
>> subexpression.
> We have to pass the information down whether we are in a conditional part,
> so we know whether we have to start a new block when we hit the temporary.
> If you're asking why we cannot start the block at the conditional point,
> the reason is that we cannot add it before we do the subexpression
> traversal (because we don't know yet whether there will be temporaries, and
> we don't want to add a block if there are no temporaries), and if we want
> to do it after the subexpression traversal, we'd somehow need to split
> blocks (as there can be nested conditionals, and multiple temporaries).
> Cheers,
> /Manuel
>> What am I missing?
>> Jordan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20140623/b641866b/attachment.html>

More information about the cfe-commits mailing list