[cfe-dev] Patch for IdentifierResolver

[Steve Naroff]

On Apr 14, 2008, at 2:12 PM, Chris Lattner wrote:

> On Apr 14, 2008, at 11:40 AM, Steve Naroff wrote:
>>> 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.
>
> Actually, we do now instantiate ParmVarDecl for function  
> prototypes.  This is required to handle prototypes like this  
> correctly:
>  int foo(int x, int A[x]);
>

Interesting...then there may be a nice space savings.

>>> 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).
>
> To reiterate, I really don't think we need to preserve  
> 'NextDeclarator'.  There is no current client of it (AFAIK), and  
> there are more efficient ways to represent it if we ever need it in  
> the future.
>

Agreed.

>>> 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).
>
> I think a simplified Decl class hierarchy is a win!
>

Sure, but we will still need predicates on VarDecl (isFile, isBlock).

Would you like me to make this change?

snaroff

> -Chris