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

[Douglas Gregor]

On Jun 15, 2010, at 4:12 PM, Fariborz Jahanian wrote:

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

Well, yes, although dangling references should be considered "undefined behavior". The two models should behave the same way when used properly.

	- Doug