[cfe-dev] CFG initializers and destructors patch

[Zhongxing Xu]

2010/9/6 Marcin Świderski <marcin.sfider at gmail.com>

> 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?


Yes, I would like we settle down the CFGElement part first, then the CFG
construction part.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20100906/a8f335a9/attachment.html>