[cfe-dev] Name lookup in ObjC methods

[Chris Lattner]

On Apr 2, 2008, at 8:30 AM, Argiris Kirtzidis wrote:

> Chris Lattner wrote:
>>> -Decl class has a ContextDecl member
>>
>> Should this be in Decl, or in ScopedDecl?  It doesn't make much  
>> sense for struct fields (for example) to have this context pointer.
>>
>>> -All Decl subclasses receive a ContextDecl at their constructors
>>
>> Sounds good, but only scopedecl if possible.
> Isn't this a bit restricting ? When NamespaceDecl is added, non- 
> ScopedDecls could be under TranslationUnitDecl or a
> specific NamespaceDecl.

Which ones?  The non-scope-decls we have are:

1) a variety of ObjC things, which are definitely not scoped (e.g.  
ObjCClass).
2) structure fields.  They will probably have a pointer up to their  
containing struct.  I guess this could be modeled as a context  
pointer, but it seems better to have a more specific concept for them  
if possible.  C++ methods may force this to change though.
3) LinkageSpec - this isn't done enough to worry about.  It's not  
clear to me that this should even be a decl.
4) FileScopeAsm - These aren't scoped.

> NamespaceDecl itself makes little sense to be a ScopedDecl, but it  
> makes sense to give it
> a context pointer to its enclosing namespace.

Are you sure?  I thought that namespaces do impact unqualified scope  
lookups.  Perhaps not though.  If they don't, then I agree it should  
go on Decl.

> Most of the non-ScopedDecls are ObjC specific but for Objective C++  
> they will be able to use NamespaceDecl
> context pointers to, for example, get their fully qualified name.

The various objc decls don't interact with C++ namespaces in ObjC++.   
They are truly global, effectively always being installed at global  
scope.

> And if RecordDecl is made a ContextDecl (mostly useful for C++), a  
> context pointer for FieldDecl would point at
> the struct/class that defined it.
>
> What do you think ?

Ok, you convinced me, adding it to Decl makes sense :)

-Chris