[cfe-dev] Decls are not synonyms for the symbols they represent

[Ted Kremenek]

On Sep 17, 2008, at 1:09 PM, steve naroff wrote:

>> Another example would be a client that wanted to rename 'x'.  How  
>> would it know all of the declarations for the same variable?  There  
>> are lots of cases where clients, looking the AST for a translation  
>> unit, want to know which declarations refer to the same thing.
>
> Absolutely. Building a cross reference map of some kind is easy to  
> do. For example, Sema has the following maps that track *all*  
> declarations for a given method (within a particular translation  
> unit):
>
>   /// Instance/Factory Method Pools - allows efficient lookup when  
> typechecking
>   /// messages to "id". We need to maintain a list, since selectors  
> can have
>   /// differing signatures across classes. In Cocoa, this happens to  
> be
>   /// extremely uncommon (only 1% of selectors are "overloaded").
>   llvm::DenseMap<Selector, ObjCMethodList> InstanceMethodPool;
>   llvm::DenseMap<Selector, ObjCMethodList> FactoryMethodPool;
>
> If maps like this are of general interest, we might consider adding  
> API to Sema to extract some of the knowledge prior to its death? As  
> an alternative, we could also post-process the AST's and build  
> whatever maps are needed. My gut says it will be a combination.

It seems to me that Sema is already building much of this information  
and then just throwing it away.  If we refactor those data structures  
to be outside of Sema, Sema could populate them for its own use and  
any client that wishes to retain them afterwards could do so.  I agree  
that it will probably end up requiring a combination of extracting  
information from Sema and then (lazily) doing some post-processing.

> I think the point we are in violent agreement about is the need for  
> "AST middleware" that sits between various clang AST clients and  
> Sema. Some of this middleware may come directly from Sema (with a  
> bit of refactoring).

Exactly my feeling as well.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20080917/98506d69/attachment.html>