[cfe-dev] Patch for IdentifierResolver

[Argiris Kirtzidis]

Chris Lattner wrote:
> Putting it in an anonymous namespace is tidy, but the big win is that 
> the methods become 'static' to the translation unit instead of being 
> externally visible.  This reduces the number of symbols exported by 
> the .o file, reducing load on the static and dynamic linker.  It also 
> gives more information to the optimizer.
>
> It's not *that* big of a deal of course, but it's a small win.

Ah, that's a good point, I've commited the suggestion:
http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20080407/005172.html
>
>>
>> I'm not sure about NextDeclarator, maybe adding a MultiDeclaratorDecl 
>> for those that need it to inherit from (using multiple inheritance 
>> like DeclContext) ?
>
> Does anything currently use this information?  I'm find with losing 
> the declarator->definition mapping if there is nothing using it right 
> now.

Currently, in a multi declaration like

int x,y,z;

the parser produces one top-level ScopedDecl (or one DeclStmt) with the 
first decl and you can get the others through decl->getNextDeclarator().
Seems to make sense to me. However, this is only useful for TypedefDecl 
and File/BlockVarDecl, is this correct ?
How about having MultiTypedefDecl, MultiFileVarDecl and 
MultiBlockVarDecl, like this:

class MultiTypedefDecl : public TypedefDecl, public MultiDeclarator {

only used for multi declarations ? MultiDeclarator will contain 
getNextDeclarator().

And BTW, now that there is a DeclContext, how about merging 
File/BlockVarDecl into a single VarDecl ?