[cfe-dev] Normalizing the AST across languages

[Doug Gregor]

On Thu, Oct 30, 2008 at 6:43 PM, Argiris Kirtzidis <akyrtzi at gmail.com> wrote:
> Doug Gregor wrote:
>>
>> Okay, good. Now, I see that CXXFieldDecls are not ScopedDecls, but
>> that's something we'll need to change, right? For example:
>>
>>  class C {
>>    int m;
>>    decltype(m) n;
>>  };
>>
>
> CXXFieldDecls don't have to be ScopedDecls, they already carry their parent
> DeclContext (the class they belong to)
> and this is enough for name lookup to find them.

Okay, I see that now. Thanks for putting up with me :)

>> So I assume that CXXFieldCollector will either be extended to support
>> other kinds of members (member types, member functions, etc.) or that
>> there will be similar collectors for those other kinds of members
>> (CXXMethodCollector, etc.)?
>>
>
> The way I saw it, as far as the AST is concerned, the instance fields of C++
> classes would be found in the 'members' array (like C structs),
> and the other member declarations (nested types, methods, static data
> members, all are ScopedDecls) would be found through a declaration chain of
> their parent DeclContext (their class),
> similar to how file scope declarations will be chained to the DeclContext of
> a namespace.
>
> Do you think this is sufficient or should something like CXXRecordDefInfo
> allocate extra space to hold all the member declarations ?

I'm concerned that putting the instance fields into one place and the
rest of the members into another place will complicate name lookup.
For example,

struct C {
  enum type { };
  char type;
};

We've already taught the IdentifierResolver to deal with these cases
appropriately, but if the first and second "type" declarations end up
in different places in the AST, we'll end up doing two name lookups
for each name, one through members and one through

I'm really starting to like the idea of just making FieldDecls into
ScopedDecls, and having the DeclContext associated with RecordType
store all of the declarations for name lookup. Auxiliary information
not found through normal lookup (base classes, constructors, etc.)
could still go into a CXXRecordDefInfo, of course. Does that seem
feasible to you?

  - Doug