[cfe-commits] r105882 - in /cfe/trunk: include/clang/AST/Decl.h lib/AST/Decl.cpp lib/Sema/SemaDecl.cpp lib/Sema/SemaTemplate.cpp

[Fariborz Jahanian]

On Jun 15, 2010, at 3:47 PM, Douglas Gregor wrote:

>
> On Jun 15, 2010, at 3:16 PM, Ted Kremenek wrote:
>
>>
>> On Jun 15, 2010, at 3:09 PM, Daniel Dunbar wrote:
>>
>>>> However, we don't really use the Destroy methods consistently, so  
>>>> they're in a state of disarray. There has been some discussion of  
>>>> eliminating them entirely (and committing to the BumpPtrAllocator  
>>>> model fully), but I don't think we're ready to commit to that (or  
>>>> to making all of the Destroy methods perfect) yet.
>>>
>>> What is left to get us to commit to that? :)
>>>
>>> - Daniel
>>
>> For me there is the issue about clients that want to modify the AST  
>> after it is built by Sema.  Do we really want all pieces of the AST  
>> to stay around, even if they are no longer referenced?
>
>
> It's not clear to me that it will be reasonable to implement such  
> clients. Removing anything from the AST is risky business, since  
> there might be references into the part of the AST you're removing.  
> We might be better off with a "transform + copy" approach to AST  
> modification, based on the ASTImporter or TreeTransform.

If I understand this correctly, BumpPtrAllocatorShould deallocates in  
one shot. So, until then, dangling references are not really dangling.
While in the Destroy model, dangling references are really dangling.  
Does this mean
clients may run into inconsistent behavior in the two allocation models?

- Fariborz

>
>
> 	- Doug
> _______________________________________________
> cfe-commits mailing list
> cfe-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits