[cfe-dev] Patch for IdentifierResolver

[Steve Naroff]

On Apr 13, 2008, at 5:11 PM, Argiris Kirtzidis wrote:

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

That's true. The NextDeclarator field isn't used for ParmVarDecl. Note  
that we don't instantiate a ParmVarDecl for function prototypes (as a  
result, we do loose the name if provided). If we did, removing this  
field would save some space.

>
> How about having MultiTypedefDecl, MultiFileVarDecl and
> MultiBlockVarDecl, like this:
>
> class MultiTypedefDecl : public TypedefDecl, public MultiDeclarator {
>
> only used for multi declarations ? MultiDeclarator will contain
> getNextDeclarator().
>

I don't think this relationship is interesting enough to call out in  
the hierarchy. In fact, after speaking briefly with Chris, it might be  
nice to consider removing the NextDeclarator field entirely. We could  
make the list a responsibility of the client. For example, we could  
change FunctionDecl to maintain the decl list explicitly. If we did  
this, we could unify iteration with parameters (which would simplify  
the API).

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

When you added DeclContext, this was my thought as well.  
Unfortunately, I was unable to come up with a benefit (other than  
removing a class). I don't believe it simplifies the code or saves any  
space (especially since we still need ParmVarDecl).

What benefit(s) do you see?

snaroff

>
>
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev