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

[Chris Lattner]

On Aug 22, 2008, at 2:08 PM, Ted Kremenek wrote:
>
> (3) ScopedDecl CHAIN: CONFLATED IMPLEMENTATION AND LACK OF ABSTRACTION

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

> PROPOSED SOLUTION
>
> 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).

Ok.

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

> PROS AND IMPLEMENTATION

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.

-Chris