[cfe-dev] [PATCH] Ordinary name lookup for class and enum names in C++

[Chris Lattner]

On Apr 12, 2008, at 6:03 PM, Doug Gregor wrote:
> Yeah, that's the first implementation that came to mind, but I didn't
> think it would pan out...
>
>> I'm sure there are more details to it than this, but avoiding  
>> creation of a
>> dummy typedef decl for every struct/class/union is a pretty big  
>> win.  What
>> drawbacks do you see?
>
> When I started coding it that way, I found that it broke an invariant
> that I really like. When we lookup what an identifier means, and we
> find out that it is a type (e.g., with isTypeName), we always get a
> typedef in C and C++. (In Objective C, we can get a ObjCInterfaceDecl,
> although I'd rather get a TypedefDecl that refers to that
> ObjCInterfaceDecl, so this is a real invariant). That's handy: it
> means that we can use ASTContext::getTypedefType to get at the actual
> type easily, rather than dealing with TypedefDecls, RecordDecls,
> EnumDecls, and ObjCInterfaceDecls separately.

Ok, I agree that it is a nice invariant (one we don't currently have,  
at least with objc), but it seems that this can be provided with a  
nicer API.  It sounds like you really want "isTypeName()" and  
"gimmeTheType(identifier)" which returns a QualType.  This could be  
done in one place, which would handle any nasties, and let the clients  
have a similar clean interface.

> Also, from an implementation standpoint, it gets a little weird to
> cope with ordinary name lookup that can find multiple things in the
> same scope and then choose among them. Say we have:
>
>  void D(int);
>  class D;
>
> When performing ordinary name lookup for 'D', we'll see the class 'D'
> first. But that's not the result of name lookup; we need to skip it
> and find the function 'D' that's in the same scope.

Right.  This namespace lookup would have to handle this case  
correctly.  Since there are a small number of namespaces, this extra  
check is pretty cheap.  We already have to do similar things in a  
couple places the scope stuff Argiris recently touched.

> But don't consider things in an outer scope:
>
>  void D(int);
>
>  namespace N {
>    class D;
>  }
>
> At this point, I decided that while it is implementable in this way,
> my gut feeling is that things are going to get messy once we get to
> dealing with namespace scopes, class scopes, etc.

This is a pretty different case.  Here, the two D's are really in two  
different Scope objects: this is a shadowing case, not a synonym-in- 
different-namespace case.  This is more analogous to:

  void D(int);
  void foo() {
    class D;
}

or:

class D;
void foo() {
   int D;
}

The two D's are very different.

-Chris