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.

1 files changed, 14 insertions, 4 deletions

diff --git a/source/slang/slang-decl-defs.h b/source/slang/slang-decl-defs.h
index 0e3159910..b4c3bcfd4 100644
--- a/source/slang/slang-decl-defs.h
+++ b/source/slang/slang-decl-defs.h
@@ -241,11 +241,21 @@ SIMPLE_SYNTAX_CLASS(RefAccessorDecl, AccessorDecl)
 
 SIMPLE_SYNTAX_CLASS(FuncDecl, FunctionDeclBase)
 
-// A "module" of code (essentiately, a single translation unit)
-// that provides a scope for some number of declarations.
-SYNTAX_CLASS(ModuleDecl, ContainerDecl)
-    FIELD(RefPtr<Scope>, scope)
+SIMPLE_SYNTAX_CLASS(NamespaceDeclBase, ContainerDecl)
+
+    // A `namespace` declaration inside some module, that provides
+    // a named scope for declarations inside it.
+    //
+    // Note: Multiple `namespace` declarations with the same name
+    // in a given module/file will be collapsed into a single
+    // `NamespaceDecl` during parsing, so this declaration does
+    // not directly represent what is present in the input syntax.
+    //
+SIMPLE_SYNTAX_CLASS(NamespaceDecl, NamespaceDeclBase)
 
+    // A "module" of code (essentiately, a single translation unit)
+    // that provides a scope for some number of declarations.
+SYNTAX_CLASS(ModuleDecl, NamespaceDeclBase)
     // The API-level module that this declaration belong to.
     //
     // This field allows lookup of the `Module` based on a