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

Doug Gregor doug.gregor at gmail.com
Sat Apr 12 18:03:12 PDT 2008


On Sat, Apr 12, 2008 at 8:06 PM, Chris Lattner <clattner at apple.com> wrote:
>  On Apr 12, 2008, at 12:54 PM, Doug Gregor wrote:
> > I briefly considered eliminating the notion of the implicit typedef,
> > and instead modifying name lookup to look into both places in C++...
> > but this approach is cleaner.
> >
>
>  Lets talk about this a bit.  I always assumed that we would modify the name
> lookup machinery to handle this instead of adding a typedef... however I
> admit that I haven't fully thought through the implications and so I may not
> see all the problems with this approach.
>
>  It seems that it would be possible to handle this by making the scope
> lookup take a bitmask of different namespaces to search.  When looking up
> 'class foo' only the tag namespace would be searched, but when looking up
> 'foo' in C++, both the tag and normal namespace would be searched.

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.

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. 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. Implicit typedefs
are conceptually simple and they have the right semantics.

  - Doug



More information about the cfe-dev mailing list