[cfe-dev] Patch for IdentifierResolver

[Argiris Kirtzidis]

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 ?
For DeclStmt maybe the info which decls are grouped can be contained in 
DeclStmt, but for global vardecls ?

And how should the parser be modified ? Currently for a global "int 
x,y,z;" it goes like this:

ParseTopLevelDecl ->
ParseExternalDeclaration ->
ParseDeclaration ->
ParseSimpleDeclaration ->
....

and ParseTopLevelDecl returns a FileVarDecl linked to the other decls 
through NextDeclarator.


-Argiris