[cfe-dev] Type>>isObjCInterfaceType() blows up

[Ted Kremenek]

On Apr 22, 2008, at 9:24 PM, Chris Lattner wrote:

>
> On Apr 22, 2008, at 9:21 PM, Sam Bishop wrote:
>
>> Chris Lattner wrote:
>>> ASTContext is very useful as a stack-based data structure.  I'm
>>> not  sure what the right fix is, but I don't really want to lose
>>> this  ability...
>>
>> What do you mean by useful?  (That's an honest question.)
>>
>> Emerson's proposed patch would allow TranslationUnit objects to
>> safely delete their ASTContext objects.  (Right now, the ASTContext
>> objects are created on the stack in the serializing case and on the
>> heap in deserializing case.  I noticed this when tracking down
>> memory leaks.)
>
> If it makes the two cases more uniform, I would be happy to "give up"
> stack allocation of ASTContext, particularly if the new scheme is for
> TranslationUnit to always own it.

One aside: if TranslationUnit always owns ASTContext, then it doesn't  
have to be explicitly allocated in TranslationUnit, just kept as a  
field.  TranslationUnit can in turn be stack or heap allocated.

I agree with Chris that ASTContext (and numerous other data structures  
in clang) are useful as stack-allocated objects.  Different clients  
can choose to stack or heap allocate ASTcontext, depending on their  
needs.  As long as their is a clear ownership policy (which includes a  
stack frame "owning" an ASTContext object), then there shouldn't be  
any issues.  Forcing ASTContext to be heap allocated just potentially  
turns one set of bugs (using released stack memory) into another  
(memory leaks from the heap) when we don't reason well about the  
lifetime of an ASTContext (or any other) object.