[cfe-dev] Patch for ContextDecl

[Argiris Kirtzidis]

Chris Lattner wrote:
>> -FieldDecl class has a ContextDecl member, so that a Field or a 
>> ObjCIvar can be traced back to their RecordDecl/ObjCInterfaceDecl easily
>
> I'm not so sure about this one :).  Ignoring ObjC for the moment, 
> Steve and I are quite concerned about the size of two classes in 
> particular: enumconstants and fielddecls.  These occur by the 
> thousands in common large headers, so they quickly dominate memory use 
> for crazy header cases. I'll ignore enums for now, which are scope 
> decls, so there isn't much we can do.
>
> C++ has a lot of interesting needs for structs: you need context info 
> (for methods), a parent class pointer, information about accessibility 
> (public/private) etc.  Adding all of this state to RecordDecl seems 
> like a bad way to go if we can avoid it: it bloats the AST for plain C 
> code, and all those fields are dead.  In addition, many structs/unions 
> and even C++ classes don't need *any* of this extra information if 
> they are sufficiently 'pod like'.  For C++ apps that #include lots of 
> C headers, for example, significant space could be saved by not having 
> this state for those structs.
>
> 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.

> 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 ?
> 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).
> Another next step: what do you think of hoisting 
> FunctionDecl::DeclChain to be a member of ContextDecl?  This would 
> allow clients to iterate over all decls in a context, likewise for 
> EnumDecl::ElementList etc?
That sounds great, I'll give a try later on.


-Argiris