[cfe-dev] Cleaning up the representation of Decls in the AST

Chris Lattner clattner at apple.com
Sat Aug 23 18:50:57 PDT 2008

On Aug 22, 2008, at 2:08 PM, Ted Kremenek wrote:

> In generally, we believe that the ScopedDecl chain should just be
> removed.  It is used in logically inconsistent ways and almost every
> client that has used it has gotten things wrong at least once.

This seems like a somewhat orthogonal problem from the rest.

> We propose the following solution to address these issues:
> - EnumDecl and NamespaceDecl no longer used the getNextDeclarator()
>  chain in ScopedDecl. Both can use a chain (as they do now), or some
>  alternate representation. However, the implementation chosen will be
>  private to each class and an iterator interface should suffice to
>  allow clients to ignore the details of the implementation.

I agree completely, since this is relatively orthogonal from the rest,  
it can be done as a first step independent from DeclGroupization

> - Introduce the notion of "DeclGroup" that represents a group of
>  (comma-separated) Decls.
> Essentially, DeclGroup would have the following grammar:
> DeclGroup -> TypeDecl Decl+
>           -> Decl

According to the C grammar lexicon, "typedecl" is a "declaration  
specifier" and "decl" is a "declarator".

> This also works for typedefs:
> typedef struct x {} foo, bar;
> becomes a DeclGroup consisting of:
> (1) A RecordDecl for 'struct x' (the "TypeDecl").
> (2) Two TypedefDecls for 'foo' and 'bar'.
> Note that this completely resolves the ownership issues with anonymous
> structs and similar constructs.  It also means that Types no longer
> own Decls (a good thing).

Presumably this means that "typedef struct x foo, bar" would be a  
DeclGroup with no "TypeDecl" but with two typedef decls?

> For the common case where a DeclGroup contains a single Decl (and no
> extra "TypeDecl" is needed), DeclGroup would have an optimized
> implementation so that using DeclGroup has no additional space
> overhead compared to our current implementation. Our idea is to
> essentially implement DeclGroup as a smart pointer, and for this
> common case it just contains the pointer to the solitary Decl (no
> additional overhead).


> - RecordDecls would represent their fields as a group of DeclGroups.
>  This enables us to accurately represent:
> struct x {
>   struct y { int z; } a, b;
>   int c;
> };

Ok.  This fixes the inconsistency with how we represent struct fields  
as well (right now we don't keep track that they are 'grouped').

> A field_iterator interface can provide the necessary abstraction to
> clients that just want to iterate over the FieldDecls of a struct.

That seems like it will be the common need for Sema at least, so that  
would be very nice.


I'm sold, totally awesome.  Nice proposal guys.

Here's another related issue that isn't really addressed: who owns the  
expressions for types?

typedef int X[1+2+x]; // vla

who owns the 1+2+x?  We have an issue in the canonical type system  
where "const X" will end up making another *type* which shares  
ownership of the expression.  This is badness, but perhaps an  
unrelated issue to the rest of the declgroup discussion here.


More information about the cfe-dev mailing list