[cfe-dev] Patch for ContextDecl

[Chris Lattner]

On Apr 4, 2008, at 3:16 PM, Argiris Kirtzidis wrote:
>> What do you think of introduce a new RecordDecl subclass:  
>> CXXRecordDecl, which provides space for all this extra stuff.  Once  
>> the parser has seen the '}' in the record definition, it can know  
>> whether the 'struct' is sufficiently simple to be cast as a  
>> RecordDecl (which is always true for c/objc, and sometimes true for  
>> C++).  If not, it creates a CXXRecordDecl.

>>
> I agree about not bloating RecordDecl and it's a very clever idea to  
> have the 'slim' RecordDecl for C++ too ,when it's appropriate.
> About the FieldDecl, is it an issue to add the pointer ? I don't  
> have a specific example of using it in a way that justifies the  
> cost, but Ted had said:

>
>> For example, I can imagine cases in the static analyzer where  
>> knowing the RecordDecl for a given structure field could  
>> potentially be very useful, and clean some things up nicely.

As usual, I don't think there is any "right" answer here :).  It's  
hard to predict what we will need in the future, and whether those  
needs can be satisfied some other way.  I do know that it is usually  
easier to leave something out and then add it on demand, rather than  
adding it early and taking it out later.  As such, I tend to prefer to  
lazily adding things :)

>> If we go down this path, I think it would make sense for  
>> CXXRecordDecl to be a DeclContext, but not for RecordDecl to be.   
>> What do you think?

> RecordDecl is a DeclContext because it inherits TagDecl. Should  
> TagDecl not be a DeclContext ?

One solution is to sink it down into EnumDecl.  However, it is  
possible that we can get ContextDecl to be free by folding the  
"DeclKind" bits into something else (the low bits of the "contained  
decls" pointer?  If ContextDecl became free, then I wouldn't feel bad  
about RecordDecl having it.

Howevever, even if RecordDecl had a ContextDecl, the question is  
whether FieldDecl gets a context pointer.  Even if RecordDecl was a  
ContextDecl, I'd argue that we should lazily add the context pointer  
to FieldDecl.

>> I agree, I think it would be nice to add back TranslationUnitDecl:  
>> it's a nice unifying concept.  There are two ways to solve the  
>> "function has a context but ObjCInterface doesn't" issue: one is to  
>> just add the pointer to objcinterface, the second is to just say  
>> "that is the way it should be".

>>
> ObjCMethodDecl already has a "NamedDecl *MethodContext" member. Can  
> this be just ObjCInterface or ObjCProtocol ?

>
> Assuming it's only these two, can we have ObjCProtocol inherit from  
> DeclContext as well and have both ObjCInterface and ObjCProtocol  
> return TranslationUnit as their context ? (by adding a pointer to  
> them as you suggested).

This is a question for Steve :)

-Chris