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

[Ted Kremenek]

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

> 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.


Hi Argiris,

I think what to do with RecordDecls (whether we merge them or not)  
will become more clear once we start implementing DeclGroups and  
TypeSpecifiers.  My concern about collapsing RecordDecls as we did  
before is the loss of information; once more of the TypeSpecifier  
logic is in place, it should become more clear what we need to keep  
and what to throw away.

The issue I am also trying to raise is whether or not RecordDecl  
really *should* be used as the key identifier for the struct.  This is  
regardless of whether or not it is plausible.  To me the RecordDecl is  
a syntactic construct, where what I would like to represent is  
something else.  Of course for efficiency we collapse concepts all the  
time, but I think it would be preferable to try to separate out some  
of these different concepts into different entities in the clang ASTs/ 
data structures.

Because a RecordDecl is a type declaration, it seems to me that we  
already have something in Clang that represents the "entity" that a  
RecordDecl refers to; in this case a RecordType.  My concern is for  
things like variables, functions, etc., which have multiple  
declarations but no one thing representing the given entity (I'm sorry  
to be fuzzy here).

As for reusing Decls for this purpose (i.e., by merging similar Decls  
together), as an analogy, in our recent discussion of TypeSpecifiers  
you originally proposed we used Type objects for that purpose, and we  
converged on the idea that TypeSpecifiers really were something wholly  
different (something we really do need).  In this case we needed a new  
data structure to capture more the of program syntax in the ASTs.  In  
this case, I'm ruminating whether or not we need something else to  
represent an aspect of the program semantics that we aren't directly  
representing.

Ted