A few weeks ago I had a conversation with Daniel about the fact that the ASTs (or other clang data structures) have no notion of the “entity” (for lack of a better word) that a declaration represents.
Here are a couple examples of what I mean:
(example 1)
extern double x;
extern double x;
Both of these are variable declarations that reference the same variable. There is no notion of the variable itself other than the declarations, which is conflated, particularly since we have multiple declarations in this case (i.e., there is no unique “entity” for the variable).
(incidentally, clang crashes on this input: http://llvm.org/bugs/show_bug.cgi?id=2760))
(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.
With structures, the unique RecordType indeed can be treated as representing the “struct” itself, which seems fine since the given declarations are just type declarations. So in this case, we do have a unique “entity” in the ASTs to represent what the declarations refer to. There are still some issues with this representation, but I will delay mentioning them until after the next example.
(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? 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?