[cfe-dev] Decls are not synonyms for the symbols they represent
kremenek at apple.com
Tue Sep 16 20:40:01 PDT 2008
On Sep 16, 2008, at 6:27 PM, Argiris Kirtzidis wrote:
>> extern int h(int* x) __attribute__((nonnull)); extern int h(int
>> 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
> 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:
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...
More information about the cfe-dev