Swap the term StdLib with Core-Module or Standard-Module in documents (#5414)

This PR is limited to documents.
All use of "Standard library" or "StdLib" are replaced with either "core module" or "standard modules", depending on the context.

6 files changed, 18 insertions, 18 deletions

diff --git a/docs/user-guide/00-introduction.md b/docs/user-guide/00-introduction.md
index 07b860d9c..6bc64dd36 100644
--- a/docs/user-guide/00-introduction.md
+++ b/docs/user-guide/00-introduction.md
@@ -98,6 +98,6 @@ Before we dive into actually _using_ Slang, let us step back and highlight some
 
 * **Predictability**: Code should do what it appears to, consistently, across as many platforms as possible. Whenever possible the compiler should conform to programmer expectation, even in the presence of "undefined behavior." Tools and optimization passes should keep their behavior as predictable as possible; simple tools empower the user to do smart things.
 
-* **Limited Scope**: The Slang system is a language, compiler, and library. It is not an engine, not a renderer, and not a "framework." The Slang system explicitly does *not* assume responsibility for interacting with GPU APIs to load code, allocate resources, bind parameters, or kick off work. While a user *may* use the Slang runtime library in their application, they are not *required* to do so.
+* **Limited Scope**: The Slang system is a language, compiler, and module. It is not an engine, not a renderer, and not a "framework." The Slang system explicitly does *not* assume responsibility for interacting with GPU APIs to load code, allocate resources, bind parameters, or kick off work. While a user *may* use the Slang runtime library in their application, they are not *required* to do so.
 
 The ordering here is significant, with earlier goals generally being more important than later ones.
diff --git a/docs/user-guide/02-conventional-features.md b/docs/user-guide/02-conventional-features.md
index 0e0f18096..e3f6336e7 100644
--- a/docs/user-guide/02-conventional-features.md
+++ b/docs/user-guide/02-conventional-features.md
@@ -275,7 +275,7 @@ enum Channel
 
 ### Opaque Types
 
-The Slang standard library defines a large number of _opaque_ types which provide access to objects that are allocated via GPU APIs.
+The Slang core module defines a large number of _opaque_ types which provide access to objects that are allocated via GPU APIs.
 
 What all opaque types have in common is that they are not "first-class" types on most platforms.
 Opaque types (and structure or array types that contain them) may be limited in the following ways (depending on the platform):
@@ -1150,4 +1150,4 @@ __init()
 {
     this = {}; //zero-initialize `this`
 }
-```
\ No newline at end of file
+```
diff --git a/docs/user-guide/07-autodiff.md b/docs/user-guide/07-autodiff.md
index 9209a903c..9fc5205e7 100644
--- a/docs/user-guide/07-autodiff.md
+++ b/docs/user-guide/07-autodiff.md
@@ -268,7 +268,7 @@ struct MyRayDifferential : IDifferentiable
     float3 d_dir;
 }
 ```
-In this case, since all fields in `MyRayDifferential` are differentiable, and the `Differential` of each field is the same as the original type of each field (i.e. `float3.Differential == float3` as defined in built-in library), the compiler will automatically use the type itself as its own `Differential`, making `MyRayDifferential` suitable for use as `Differential` of `MyRay`.
+In this case, since all fields in `MyRayDifferential` are differentiable, and the `Differential` of each field is the same as the original type of each field (i.e. `float3.Differential == float3` as defined in the core module), the compiler will automatically use the type itself as its own `Differential`, making `MyRayDifferential` suitable for use as `Differential` of `MyRay`.
 
 We can also choose to manually implement `IDifferentiable` interface for `MyRayDifferential` as in the following code:
 
@@ -487,7 +487,7 @@ void back_prop(
 
 ## Builtin Differentiable Functions
 
-The following built-in functions are backward differentiable and both their forward-derivative and backward-propagation functions are already defined in the built-in library:
+The following built-in functions are backward differentiable and both their forward-derivative and backward-propagation functions are already defined in the core module:
 
 - Arithmetic functions: `abs`, `max`, `min`, `sqrt`, `rcp`, `rsqrt`, `fma`, `mad`, `fmod`, `frac`, `radians`, `degrees`
 - Interpolation and clamping functions: `lerp`, `smoothstep`, `clamp`, `saturate`
diff --git a/docs/user-guide/08-compiling.md b/docs/user-guide/08-compiling.md
index 623a3111f..8fd94ff3c 100644
--- a/docs/user-guide/08-compiling.md
+++ b/docs/user-guide/08-compiling.md
@@ -266,19 +266,19 @@ The `slangc` compiler provides a few conveniences for command-line compilation:
 You can compile a `.slang` file into a binary IR module. For example, given the following source:
 
 ```hlsl
-// library.slang
+// my_library.slang
 float myLibFunc() { return 5.0; }
 ```
 
-You can compile it into `library.slang-module` with the following slangc command line:
+You can compile it into `my_library.slang-module` with the following slangc command line:
 
 ```bat
-slangc library.slang -o library.slang-module
+slangc my_library.slang -o my_library.slang-module
 ```
 
-This allows you to deploy just the `library.slang-module` file to users of the library, and it can be consumed in the user code with the same `import` syntax:
+This allows you to deploy just the `my_library.slang-module` file to users of the module, and it can be consumed in the user code with the same `import` syntax:
 ```hlsl
-import library;
+import my_library;
 ```
 
 ### More Options
@@ -329,8 +329,8 @@ Slang::ComPtr<IGlobalSession> globalSession;
 createGlobalSession(globalSession.writeRef());
 ```
 
-When a global session is created, the Slang system will load its internal representation of the _standard library_ that the compiler provides to user code.
-The standard library can take a significant amount of time to load, so applications are advised to use a single global session if possible, rather than creating and then disposing of one for each compile.
+When a global session is created, the Slang system will load its internal representation of the _core module_ that the compiler provides to user code.
+The core module can take a significant amount of time to load, so applications are advised to use a single global session if possible, rather than creating and then disposing of one for each compile.
 
 > #### Note ####
 > Currently, the global session type is *not* thread-safe.
@@ -611,8 +611,8 @@ The only functions which are currently thread safe are
 ```C++
 SlangSession* spCreateSession(const char* deprecated);
 SlangResult slang_createGlobalSession(SlangInt apiVersion, slang::IGlobalSession** outGlobalSession);
-SlangResult slang_createGlobalSessionWithoutStdLib(SlangInt apiVersion, slang::IGlobalSession** outGlobalSession);
-ISlangBlob* slang_getEmbeddedStdLib();
+SlangResult slang_createGlobalSessionWithoutCoreModule(SlangInt apiVersion, slang::IGlobalSession** outGlobalSession);
+ISlangBlob* slang_getEmbeddedCoreModule();
 SlangResult slang::createGlobalSession(slang::IGlobalSession** outGlobalSession);
 const char* spGetBuildTagString();
 ```
diff --git a/docs/user-guide/a1-03-obfuscation.md b/docs/user-guide/a1-03-obfuscation.md
index abce92e12..dab216940 100644
--- a/docs/user-guide/a1-03-obfuscation.md
+++ b/docs/user-guide/a1-03-obfuscation.md
@@ -169,13 +169,13 @@ slangc module-source.slang -o module.zip -g -obfuscate
 
 This will compile "module-source.slang" into SlangIR module (aka `slang-module`) and places the `.slang-module` inside of the zip. As obfuscation is enabled the .zip will also contain the obfuscated source map for the module. 
 
-The `.zip` file can now be used and referenced as a library 
+The `.zip` file can now be used and referenced as a module 
 
 ```
 slangc source.slang -target dxil -stage compute -entry computeMain -obfuscate -r module.zip
 ```
 
-Notice here that the `-r` library reference is to the `.zip` file rather than the more usual `.slang-module` that is contained in the zip file. By referencing the library in this way Slang will automatically associate the contained obfuscated source map with the module. It will use that mapping for outputting diagnostics.
+Notice here that the `-r` module reference is to the `.zip` file rather than the more usual `.slang-module` that is contained in the zip file. By referencing the module in this way Slang will automatically associate the contained obfuscated source map with the module. It will use that mapping for outputting diagnostics.
 
 It is also worth noticing that in this second compilation, using `module.zip`, we need the `-obfuscate` flag set. If this isn't set linking will not work correctly.
 
@@ -256,7 +256,7 @@ Why you might not want to use an emit source map
 * The `#line` mechanism doesn't require any special handling, and the mapping back is embedded directly into the emitted source/output binary
 * There is more housekeeping in getting keeping and using source maps
 * Currently Slang doesn't directly expose a source map processing API directly  
-  * We do support source maps in library files, or produced as part of a compilation
+  * We do support source maps in module files, or produced as part of a compilation
   * A developer could use the slang `compiler-core` implementation
   * In the future the project could provide some API support 
 
diff --git a/docs/user-guide/a1-04-interop.md b/docs/user-guide/a1-04-interop.md
index a13f75c48..a13bb5ca2 100644
--- a/docs/user-guide/a1-04-interop.md
+++ b/docs/user-guide/a1-04-interop.md
@@ -110,7 +110,7 @@ void test_0()
 The strings in `__requirePrelude` are deduplicated: the same prelude string will only be emitted once no matter how many times an intrinsic function is invoked. Therefore, it is good practice to put `#include` lines as separate `__requirePrelude` statements to prevent duplicate `#include`s being generated in the output code.
 
 ## Managing Cross-Platform Code
-If you are defining an intrinsic function that maps to multiple targets in different ways, you can use `__target_switch` construct to manage the target-specific definitions. For example, here is a snippet from Slang's builtin standard library that defines `getRealtimeClock`:
+If you are defining an intrinsic function that maps to multiple targets in different ways, you can use `__target_switch` construct to manage the target-specific definitions. For example, here is a snippet from the Slang core module that defines `getRealtimeClock`:
 ```hlsl
 [__requiresNVAPI]
 __glsl_extension(GL_EXT_shader_realtime_clock)