[cfe-dev] CFG initializers and destructors patch

Marcin Świderski marcin.sfider at gmail.com
Sun Sep 5 22:44:22 PDT 2010


W dniu 6 września 2010 05:37 użytkownik Zhongxing Xu
<xuzhongxing at gmail.com>napisał:

> Hi Marcin,
>
> Thank you for working on this. This patch is really big. I suggest we focus
> on the 'CFGElement' aspect in the first patch, and put the 'LocalScope'
> things in later patches.
>
> About CFGElement, I think we an avoid using two pointers in it. Currently
> the second pointer data is used for 'the statement that triggers the dtor. I
> think we don't need a pointer for it. The position where the CFGElement
> resides is the place where it is triggered. It is not triggered by a
> statement.
>
> Then for the rest one pointer, we let it point to the VarDecl for
> AutomaticObjectDtor, to the initializer for Base and Member dtors, to
> CXXBindTemporaryExpr for temporary dtor.
>
> 2010/9/3 Marcin Świderski <marcin.sfider at gmail.com>
>
>  Hi
>>
>> I'm sending a patch with implementation of C++
>> - initializers from constructor initialization list,
>> - implicit destructors for objects with automatic storage duration.
>>
>> For destructors I've taken care of:
>> - block local scopes,
>> - if/switch/for/while/do local scopes (in case there's no block),
>> - if/switch/for/while condition variables,
>> - catch exception variable,
>> - temporaries bound to const reference.
>>
>> Is there something that I've missed?
>>
>> As it have been suggested I've created hierarchy of CFGElements. Currently
>> there're two unused types for implicit destructor calls in destructor. I've
>> did not revert ability of CFGElement to cast/dyn_cast to Stmt, because it
>> would lead to situation when cast<Stmt>(SomeCFGElement) would return null. I
>> did however add method for downcasting CFGElement object to object of its
>> implemntation class (returned by value, not pointer) with returning invalid
>> object on invalid cast.
>>
>> I did not add CFGElement for destructors of temporary objects. After
>> giving it some thought I came to a conclusion that it shouldn't be covered
>> by CFG, because it clearly needs path-sensitiveness.
>>
>> Cheers
>> Marcin
>>
>
> Should I split it and send it cfe-commits with some comments?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20100906/8c726c21/attachment.html>


More information about the cfe-dev mailing list