[cfe-dev] Patch for IdentifierResolver

[Steve Naroff]

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

Understood. Note that we don't preserve the decl list in all cases  
anyway (e.g. FieldDecl).

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

For global vardecls, we could create a DeclList object (instantiated  
in Sema::FinalizeDeclaratorGroup). This object would only be created  
when needed. In headers, I imagine it would be uncommon (most  
FunctionDecls aren't declared within a list context).

Another idea is to have the TranslationUnitDecl contain a list of all  
the top level decls. We could then add a "FirstDeclInList" bit (to  
Decl). This would enable AST clients to preserve the list when  
necessary.

These are just 2 ideas.

snaroff

> 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