[cfe-dev] Patch for ContextDecl

Chris Lattner clattner at apple.com
Sat Apr 5 21:51:14 PDT 2008


On Apr 5, 2008, at 6:05 PM, Argiris Kirtzidis wrote:

> Hi,
>
> The attached patch contains these changes:
>
> -Renamed ContextDecl -> DeclContext
> -Removed DeclContext pointer from FieldDecl
> -EnumDecl inherits from DeclContext, instead of TagDecl

Looks great to me, applied!:
http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20080331/005016.html

When the context work settles down, please send in an updated version  
of your namespace patch, I'd like to get that in at some point too :).

> Chris Lattner wrote:
>> 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?

> The issue is that there's no convention on how the chain will be  
> traversed, FunctionDecl's members use getNext() and EnumDecl's  
> members use getNextDeclarator().

Ok, we can change them to a unified name.

> And both getNext() and getNextDeclarator() are not suitable for  
> general "decls in context iteration" since they have other uses.

Ok.

> For FunctionDecl, getNext() changes from "point to shadowed decl  
> with same id" to "point to next decl of function", but for other  
> contexts (like namespaces) it may be
> required to stay "point to decl of same id".
> If there's a need later on, a solution may be to add another  
> dedicated pointer in ScopedDecl to serve as a "point to next decl in  
> context".

I'm not sure I follow this.  What is actually going on here is that  
getNext is horribly overloaded for scope decls.  When parsing is  
happening, the "next" pointer is used to represent the scope chains  
hanging off the identifier info.  This keeps track of shadowing.   
However, after parsing is done, these fields are dead, so they are  
"repurposed" to be the linked list of decls within a context (e.g.  
functiondecl).

A truly elegant solution would be to get rid of parsing-specific stuff  
from the AST, but I'm not sure how to do this while retaining  
efficiency at parse time for walking and maintaining the shadow stacks.

-Chris



More information about the cfe-dev mailing list