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