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! :) _______________________________________________ cfe-dev mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
