diff options
| author | Yong He <yonghe@outlook.com> | 2023-12-13 16:39:46 -0800 |
|---|---|---|
| committer | GitHub <noreply@github.com> | 2023-12-13 16:39:46 -0800 |
| commit | 7e7d9ce142c3ef077743496cbf8cdc8f669a66af (patch) | |
| tree | cabcc19ab27e638877d5d12080377f50f01e6f1a /docs/user-guide | |
| parent | 3979660d4fe1fd6c1f1d9b8956e96817e17c3f4e (diff) | |
Polish language server and documentation. (#3410)
Co-authored-by: Yong He <yhe@nvidia.com>
Diffstat (limited to 'docs/user-guide')
| -rw-r--r-- | docs/user-guide/03-convenience-features.md | 5 | ||||
| -rw-r--r-- | docs/user-guide/04-modules-and-access-control.md | 24 |
2 files changed, 21 insertions, 8 deletions
diff --git a/docs/user-guide/03-convenience-features.md b/docs/user-guide/03-convenience-features.md index 4957f267e..eefd9fc63 100644 --- a/docs/user-guide/03-convenience-features.md +++ b/docs/user-guide/03-convenience-features.md @@ -87,13 +87,16 @@ namespace ns You can also use the `using` keyword to pull symbols defined in a different namespace to the current scope, removing the requirement for using fully qualified names. -```csharp +```cpp namespace ns1.ns2 { int f(); } using ns1.ns2; +// or: +using namespace ns1.ns2; // alternative syntax. + void test() { f(); } // OK. ``` diff --git a/docs/user-guide/04-modules-and-access-control.md b/docs/user-guide/04-modules-and-access-control.md index 7f6ec91a5..68e2d06c7 100644 --- a/docs/user-guide/04-modules-and-access-control.md +++ b/docs/user-guide/04-modules-and-access-control.md @@ -59,9 +59,13 @@ void f_b() { f_a(); } // c.slang implementing "m.slang"; // alternate syntax. -// OK to use f_a and f_b because they are part of module `m`, even -// if we are not including `a` and `b` here. -void f_c() { f_a(); f_b(); } + +void f_c() +{ + // OK, `c.slang` is part of module `m` because it is `__include`'d by + // `m.slang`. + f_a(); f_b(); +} // m.slang module m; @@ -79,8 +83,14 @@ __include "dir/file-name.slang"; __include "dir/file-name"; ``` +Also note that a file is considered a part of a module only if the file can be discovered +via transitive `__include`s from the primary module file. It is possible to have a dangling +file with the `implementing` declaration that is not `__include`'d by any other files in +the module. Such dangling files will not be considered as part of the module and will not +be compiled. The `implementing` declaration is for the purpose of verification and language server code assisting, and does not carry any other semantics that affect compilation. + > #### Note #### -> When using the identifier token syntax, Slang will translate any underscores(`_`) to hyphenators("-") to obtain the file name. +> When using the identifier token syntax, Slang will translate any underscores(`_`) to hyphens("-") to obtain the file name. ## Importing a Module @@ -150,14 +160,14 @@ module a; __include b; public struct PS { - int internalMember; + internal int internalMember; public int publicMember; } internal void f() { f_b(); } // OK, f_b defined in the same module. // b.slang implementing a; -internal void f_b(); // Defines f_b in module a so they can within the module. +internal void f_b(); // Defines f_b in module `a`. public void publicFunc(); // m.slang @@ -190,7 +200,7 @@ The Slang compiler enforces the following rules regarding access control: Slang used to not have support for access control, and all symbols were treated as having `public` visibility. To provide compatibility with existing code, the Slang compiler will detect if the module is written in the legacy language, and treat all symbols as `public` if so. A module is determined to be written in legacy language if all the following conditions are met: -- The module is lacking `module` declaration at the begining. +- The module is lacking `module` declaration at the beginning. - There is no use of `__include`. - There is no use of any visibility modifiers -- `public`, `private` or `internal`. |
