[cfe-dev] Name lookup in ObjC methods

[Argiris Kirtzidis]

Chris Lattner wrote:
>> 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.
I see what you mean, a ScopedDecl is something that can "shadow" another 
decl, right ? It makes perfect sense then.
>> 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.
Oh, I really should refrain from making assertions about ObjC in the 
future ;)
>> 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 :)
I'm less convinced than before but at least for the "unifying concept of 
context" as Ted said and for RecordDecls, maybe it's worth it for now.
Another idea would be:
-Make Field a ScopedDecl too (at least it makes some sense for C++), and 
use a ContextDecl member only to ScopedDecl.
-Remove TranslationUnitDecl because otherwise, FunctionDecl would return 
TranslationUnitDecl as its context and ObjCMethodDecl would
return NULL (by ContextDecl::getParent()); a bit inconsistent.
The convention would be that a ContextDecl chain ends at NULL, instead 
of a TranslationUnitDecl.
> Would it be possible to move ContextDecl to a ContextDecl.h file that 
> Decl.h #includes?
"ContextDecl.h" would require the Decl class to be defined because the 
ContextDecl class uses the Decl::Kind enum. Should I move the Decl class 
to a "BaseDecl.h" or something ?


PS. Thanks to Chris and Ted, for their kind words. LLVM/clang are really 
exciting projects to be involved with! :)