From 487d4a4f406c9dd9803ecdca02467d09ee1ecf4a Mon Sep 17 00:00:00 2001 From: Tim Foley Date: Thu, 2 Apr 2020 08:52:42 -0700 Subject: Add basic support for namespaces (#1304) This change adds logic for parsing `namespace` declarations, referencing them, and looking up their members. * The parser changes are a bit subtle, because that is where we deal with the issue of "re-opening" a namespace. We kludge things a bit by re-using an existing `NamespaceDecl` in the same parent if one is available, and thereby ensure that all the members in the same namespace can see on another. * In order to allow namespaces to be referenced by name they need to have a type so that a `DeclRefExpr` to them can be formed. For this purpose we introduce `NamespaceType` which is the (singleton) type of a reference to a given namespace. * The new `NamespaceType` case is detected in the `MemberExpr` checking logic and routed to the same logic that `StaticMemberExpr` uses, and the static lookup logic was extended with support for looking up in a namespace (a thin wrapper around one of the existing worker routines in `slang-lookup.cpp`. * I made `NamespaceDecl` have a shared base class with `ModuleDecl` in the hopes that this would allow us to allow references to modules by name in the future. That hasn't been tested as part of this change. * I cleaned up a bunch of logic around `ModuleDecl` holding a `Scope` pointer that was being used for some of the more ad hoc lookup routines in the public API. Those have been switched over to something that is a bit more sensible given the language rules and that doesn't rely on keeping state sititng around on the `ModuleDecl`. * I added a test case to make sure the new funcitonality works, which includes re-opening a namespace, and it also tests both `.` and `::` operations for lookup in a namespace. * The main missing feature here is the ability to do something like C++ `using`. It would probably be cleanest if we used `import` for this, since we already have that syntax (and having both `import` and `using` seems like a recipe for confusion). Most of the infrastructure is present to support `import`ing one namespace into another (in a way that wouldn't automatically pollute the namespace for clients), but some careful thought needs to be put into how import of namespaces vs. modules should work. --- source/slang/slang.cpp | 24 +++++------------------- 1 file changed, 5 insertions(+), 19 deletions(-) (limited to 'source/slang/slang.cpp') diff --git a/source/slang/slang.cpp b/source/slang/slang.cpp index 6c1a59ea4..aefe70a4a 100644 --- a/source/slang/slang.cpp +++ b/source/slang/slang.cpp @@ -890,24 +890,13 @@ Type* ComponentType::getTypeFromString( // the modules that were directly or // indirectly referenced. // - // TODO: This `scopesToTry` idiom appears - // all over the code, and isn't really - // how we should be handling this kind of - // lookup at all. - // - List> scopesToTry; - for(auto module : getModuleDependencies()) - scopesToTry.add(module->getModuleDecl()->scope); + RefPtr scope = _createScopeForLegacyLookup(); auto linkage = getLinkage(); - for(auto& s : scopesToTry) - { - RefPtr typeExpr = linkage->parseTermString( - typeStr, s); - type = checkProperType(linkage, TypeExp(typeExpr), sink); - if (type && !type.as()) - break; - } + RefPtr typeExpr = linkage->parseTermString( + typeStr, scope); + type = checkProperType(linkage, TypeExp(typeExpr), sink); + if( type ) { m_types[typeStr] = type; @@ -915,9 +904,6 @@ Type* ComponentType::getTypeFromString( return type; } - - - CompileRequestBase::CompileRequestBase( Linkage* linkage, DiagnosticSink* sink) -- cgit v1.2.3