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

[Argiris Kirtzidis]

Hi Ted,

Ted Kremenek wrote:
> (example 2)
>
>   struct s;
>   struct s { int a; };
>   struct s;
>
> Until a few weeks ago, these struct declarations were represented by a 
> single RecordDecl with a unique RecordType.  Now they are represented 
> by three separate RecordDecls with a shared, unique RecordType.

What do you think about the idea of going back to single RecordDecls and 
using DeclGroups to represent the above example ?

struct s; -> typespecifier ';' -> DeclGroup with TypeSpecifier 
referencing 's' and empty declaration list
struct s { int a; }; -> typespecifier ';' -> DeclGroup with 
TypeSpecifier defining 's' and empty declaration list

And only one RecordDecl will be created for 's'.

Or maybe make it more explicit by introducing a TypeSpecDecl for these 
constructs.

>
> (example 3)
>
> int f();
> int f();
> int f() { return 0; }
>
> int g();
> int g() { return 1; }
>
> For this example, we have separate FunctionDecls for each one of these 
> declarations.  In this example, all of the declarations both 'f' and 
> 'g' share the same type (note that this is different from the case 
> with structs).  For the case of 'f', all of its FunctionDecls are 
> chained together, and the same goes for 'g'.  There is, however, no 
> notion of an entity or concept in the ASTs or other clang data 
> structures that represent 'f' itself.
>
> Here is an example of why not having an explicit concept for 'f', 'g', 
> or any symbol is problematic.
>
> 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.
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

-Argiris

>  Given one of these FunctionDecls, I would have to iterate the chain 
> of FunctionDecls and query each one of its attributes.  This seems a 
> little cumbersome, and causes separate clients to have to implement 
> their own logic for querying information about "symbols" in a 
> translation unit.  It also causes clients to think about internal 
> representations such as the fact that FunctionDecls are chained, 
> something we may wish to change at any moment in the future.
>
> This email isn't really a proposal of a solution; I'm just raising an 
> issue to see if anyone has any comments.  After the last few weeks 
> I've been excited by our discussions of DeclGroups and TypeSpecifiers 
> that will solve many of the remaining issues with faithfully 
> representing syntax in the ASTs.  At the same time, I think we need to 
> pay a little more attention to the semantics, and providing 
> infrastructure that would be useful for many clients.
>
> Indeed, some of our changes to improve our capturing of syntax have 
> actually weakened some of our clients reasoning about semantics.  For 
> example, by splitting separate struct declarations into multiple 
> RecordDecls we actually (initally) broke CodeGen because the CodeGen 
> library assumed that there was a direct 1-1 mapping between a 
> RecordDecl and the concept it represented.  That particular case was 
> easily resolved by using the RecordType instead of the RecordDecl to 
> represent the 'struct', but I'd be willing to wager that there are 
> other issues that haven't surfaced yet because RecordTypes are being 
> used in this way (by all clients).
>
> Thoughts?
> ------------------------------------------------------------------------
>
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
>