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

[Ted Kremenek]

On Sep 16, 2008, at 6:27 PM, Argiris Kirtzidis wrote:

>> Consider:
>>
>>  extern int h(int* x) __attribute__((nonnull));   extern int h(int  
>> *x);
>>  extern int h(int* x) __attribute__((noreturn));
>> This code is completely valid.  In the ASTs we create three  
>> FunctionDecls, the first having the attribute "nonnull" attached to  
>> it (and object of type NonNullAttr) and the third having the  
>> attribute "noreturn" attached to it (an object of type NoReturnAttr).
>>
>> Suppose I had a client (e.g., code generation, static analysis)  
>> that wanted to know all the attributes attached to a given  
>> function. How would I go about doing this?
>
> If I'm not mistaken, the latest declaration is supposed to "merge"  
> the information from all previous declarations through  
> Sema::MergeFunctionDecl, and that includes attributes.

To my chagrin I was not aware of this.  Thanks for pointing it out!

The problem I have with this approach is that it relies on the ASTs  
being constructed in a very special way.  Sema of course has to do the  
right thing, but what about other entities that create or modify  
ASTs?  Put another way, it is not clear to me, from looking at the  
ASTs, that the invariant you mentioned is in place.  It's just  
something that is silently there because of the way Sema does things.

>
> The client would only need to query information from the latest  
> declaration.
>
> FYI, there was a long-winded discussion on what is a good way to  
> combine the information from all FunctionDecls and use the same  
> FunctionDecl pointer throughout the AST, here:
> http://lists.cs.uiuc.edu/pipermail/cfe-dev/2008-April/001479.html
> http://lists.cs.uiuc.edu/pipermail/cfe-dev/2008-May/001608.html
>


My own feeling, and from reviewing the threads you mentioned and from  
looking over the recent discussions on this list, that reusing Decls  
(either by merging them, changing SourceLocations, etc.) just doesn't  
seem right.  Gradually mutating the Decl objects as we construct the  
rest of the AST for a translation unit just seems messy, and makes  
modifying or creating AST nodes error prone.  Reusing Decls to me  
makes it inherently harder to capture the way a user wrote the code.   
I'm willing to put this part of the argument, however, until we have  
actually gone and implemented some of TypeSpecifier and DeclGroup to  
see what we are left with.

To me declarations represent syntax, and should reference the thing  
they are declaring.  RecordDecls already do this with RecordTypes  
(since there is a many-to-one mapping here), but we don't have a  
similar concept for variables and functions.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20080916/c63a7dab/attachment.html>