[cfe-dev] Decls are not synonyms for the symbols they represent

Ted Kremenek kremenek at apple.com
Wed Sep 17 10:32:00 PDT 2008

On Sep 17, 2008, at 8:09 AM, Steve Naroff wrote:

> As far as the AST's go, I really don't see the hardship here. The  
> fact that the FunctionDecls are chained accurately reflects the  
> source code...doesn't it? For me, the problem with the chain is  
> memory efficiency (more than convenience). In C, it is fairly  
> uncommon to have more than one function decl for the same name (yet  
> every FunctionDecl has a chain!). Nevertheless, we already have some  
> bloat in FunctionDecl...every prototype has a Body slot (ouch).  
> Clearly room for improvement here.

I'm actually not arguing about adding anything to the AST.  I agree  
with you and Argiris that we should keep the ASTs to faithfully  
representing the syntax.  My issue has more to resolving which  
declarations refer to the same entity.  Your IdResolver idea (below)  
is more or less what I was thinking of.

> A related issue which I consider more problematic is the lack of  
> *any* "chain" for VarDecls. Consider the following code:
> int i4;
> int i4;
> extern int i4;
> const int a [1] = {1};
> extern const int a[];
> extern const int b[];
> const int b [1] = {1};
> At the moment, there is no way to get to the previous declaration!  
> Since I've already whined about the memory inefficiency for  
> FunctionDecl's, I certainly wouldn't recommend adding a chain for  
> all VarDecls!


> I remember writing Sema::CheckForFileScopedRefefinitions() where I  
> had to deal with this. Fortunately, Sema's "IdResolver" came to the  
> rescue (thanks Argiris:-). That said, my gut says it might be worth  
> using an IdResolver-like mechanism to solve this "navigation  
> problem" for *both* VarDecls and FunctionDecls. Architecturally, it  
> would make sense for this new API to be part of ASTContext.

Sounds great to me.  What I would like to see is a nice way for  
clients of the ASTs to go from syntactic constructs (e.g.  
declarations) to the higher-level concepts.  I don't want to add bloat  
to the AST; the problem is that some of this information just simply  
cannot be recovered once we exit Sema.  I think having the notion of  
an IdResolver in ASTContext seems like a very reasonable idea; not  
certain about the performance characteristics.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20080917/d08cf0f9/attachment.html>

More information about the cfe-dev mailing list