[cfe-dev] Better type-specifier representation

[Ted Kremenek]

On Sep 12, 2008, at 3:11 PM, Argiris Kirtzidis wrote:

> This is what I'm suggesting against: over-complicating the AST by
> introducing various Decls or Exprs for providing information for
> something that is fundamentally part of a type-specifier.
>
> -We will introduce additional Decls for distinction between new type
> definition or reference in declarations (simpler option is not to
> introduce additional decls)
> -Use DeclGroup for function parameters (even if there's no overhead,
> using ParmVarDecl is the simpler option)
> -introduce some kind of decl or expression for the struct in "sizeof
> (struct {})" (simpler option is to use a Type, as we do now)
> -The same for casts "(struct{}) x"
> -in C++ use additional decl (or DeclGroup ?) for a condition
> declaration: "if (struct {}* x = 0) {}" (simpler option is to use a
> single VarDecl as now)
> -Something to distinguish C++ new: "new struct{}()"
>
> There must be other places where trying to distinguish between
> reference/definition is going to complicate things, basically anywhere
> that a type may be used, this is off the top of my head.
>
> All these cases can be handled uniformly and in a much simpler way by
> introducing the RecordDefType, and making the distinction based on the
> thing which actually carries the ambiguity (the type-specifier).

Hi Argiris,

I'm fine with introducing the notion of a type-specifier into the AST,  
and it would potentially clean up a whole bunch of loose ends and more  
closely follow the grammar.  From the points you have made, I can see  
how it would be very useful, and is compatible with the notion of a  
DeclGroup.  In fact, the "prefix" of the DeclGroup could just be a  
type-specifier object.

My feeling is that type-specifiers are different than types.  They  
aren't synonymous; one is a syntactic construct, the other a semantic  
concept, and they shouldn't be treated as being the same in the ASTs.   
I think that type-specifiers could possibly be encoded as a smart  
pointer or a similar class (similar to QualType) to make the overhead  
negligible.

Ted