[cfe-dev] Patch for IdentifierResolver

[Steve Naroff]

On Apr 14, 2008, at 3:59 PM, Chris Lattner wrote:

>
> On Apr 14, 2008, at 3:09 PM, Argiris Kirtzidis wrote:
>
>> Steve Naroff wrote:
>>>>>> 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.
>>
>> From a compiler's perspective, the difference between
>>
>> int x,y;
>>
>> and
>>
>> int x;
>> int y;
>>
>> is meaningless, but for a source code analysis/refactoring tool  
>> it'd be useful to keep the AST close to the source code.
>>
>> Assuming that you want to distinguish grouped decls without  
>> NextDeclarator, how would it work ?
>
> Hi Argiris,
>
> I really think we should just remove this, and add it if actually  
> needed by a client.  While we could probably merge this in somehow  
> in a low-cost way, it would increase the complexity of the code,  
> which is itself a loss...
>

fyi...ScopedDecl::getNextDeclarator() is currently used in 31 places.  
For DeclStmt/EnumDecl, it should be trivial to remove (they can just  
implement the list explicitly). There are other cases (like  
ScopedDecl::EmitOutRec()) that might require a little work. It's also  
a little odd that RecordDecl currently depends on it.

Do you think the effort to remove it is worth the cleanup? Seems like  
it's being used quite a bit (though some of the uses are probably  
questionable). I tend to agree with you, however wanted to double  
check (realizing it isn't a real low cost cleanup...).

snaroff

> -Chris
>