On Mon, Jul 7, 2014 at 8:05 PM, Jordan Rose <[email protected]> wrote:

>
> On Jul 7, 2014, at 10:50 , Manuel Klimek <[email protected]> wrote:
>
> On Mon, Jul 7, 2014 at 7:42 PM, Jordan Rose <[email protected]> wrote:
>
>>
>> On Jul 7, 2014, at 10:41 , Manuel Klimek <[email protected]> wrote:
>>
>> On Mon, Jul 7, 2014 at 7:38 PM, Jordan Rose <[email protected]>
>> wrote:
>>
>>>
>>> On Jul 7, 2014, at 10:37 , Manuel Klimek <[email protected]> wrote:
>>>
>>> On Mon, Jul 7, 2014 at 7:29 PM, Jordan Rose <[email protected]>
>>> wrote:
>>>
>>>>
>>>> On Jul 7, 2014, at 10:28 , Manuel Klimek <[email protected]> wrote:
>>>>
>>>> On Mon, Jul 7, 2014 at 6:48 PM, Jordan Rose <[email protected]>
>>>> wrote:
>>>>
>>>>> Can you add an assertion at the end of a block that there are no
>>>>> outstanding temporary destructors in the current stack frame? That seems
>>>>> useful.
>>>>>
>>>>
>>>> Do you mean at the end of a VisitBlockDecl?
>>>>
>>>>
>>>> No, during the path-sensitive run, so handleBlockExit.
>>>>
>>>
>>> So you mean at the end of a CFG block? But here we might have
>>> outstanding temporary dtors open (?)
>>>
>>>
>>> Oops, right. Was thinking too much in terms of AST structure. How about
>>> at the end of a function (inlined or not)?
>>>
>>
>> Could we say every time we transition from a block with a temp dtor
>> terminator to a block that does not have a temp dtor terminator (or an
>> unconditional terminator) we check?
>>
>>
>> That sounds correct, but misses the case where we built the CFG wrong
>> (forgetting to add the branch in the correct place and thus never getting
>> to the temp dtor block at all).
>>
>
> Makes sense. Do you have a hint where the right place on function exit to
> check it would be? :)
>
>
> *checks* ExprEngine::processEndOfFunction.
>

Hm, so we'll need to adjust the data structure to be indexed by stack frame
somehow (use a map) instead of the pair<expr, stack-frame>?
_______________________________________________
cfe-commits mailing list
[email protected]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits

Reply via email to