[cfe-dev] Ownership of declarations in clang?

[Ted Kremenek]

On Feb 25, 2008, at 3:13 PM, Chris Lattner wrote:

>>
>> I was looking at this using
>> valgrind, and then I was trying to figure out what code is supposed  
>> to
>> be responsible for cleaning up the declarations generated by Sema
>> after the file is finished being parsed.  I wasn't able to find any
>> such code.
>
> Ted may know better than me at this point, but I think the idea is
> that the TranslationUnit object should own (and thus destroy) the
> decls when it is torn down.

The TranslationUnit object is currently only used when serializing/ 
deserializing ASTs from Bitcode.  When building ASTs from source,  
lines 1252-1296 of clang.cpp construct the SourceManager object,  
Preprocessor, and then calls ProcessInputFile (which then just streams  
ASTs to an ASTConsumer).  In this scenario there is now ownership of  
the top-level decls.

The TranslationUnit object can be easily modified to have its dstor  
delete the top-level decls that it owns.  That's not the big problem.   
The major issue is that when we parse source we aren't using  
TranslationUnit or some similar abstraction to encapsulate ownership  
of the ASTs.

>> What exactly is the expected ownership model for the declarations
>> generated by Sema?  They obviously need to be around until we are
>> finished parsing the file, but by then, it appears only the parser
>> (specifically, the root scope) is holding onto pointers to
>> declarations, and it doesn't know how to delete them.
>
> TranslationUnit should own them.  I don't know what its current state
> is, Ted?

This is where I think things should go.  It was cludged together  
enough to get serialization working, but the driver needs to be  
reworked to integrate TranslationUnit into the default parsing process.

The other issue is whether or not TranslationUnit and ASTContext  
should just be merged.  Over time, while I was working on the  
serializer, I think it was decided to have one ASTContext/ 
SourceManager per translation unit.  If this still is the case,  
perhaps having both entities is redundant.

> Also, I'm not sure if all the virtual dtors for the various AST nodes
> are deleting their children right now.

We don't do any cleanup of this kind at all right now.  The virtual  
dstors for AST nodes have never been implemented.  We talked about  
doing this, but it remains a TODO.