summaryrefslogtreecommitdiffstats
path: root/docs
diff options
context:
space:
mode:
authoraidanfnv <aidanf@nvidia.com>2025-07-27 09:58:31 -0700
committerGitHub <noreply@github.com>2025-07-27 16:58:31 +0000
commit6d399804a353154259cf4410940f144db8f9b5cf (patch)
treeb4049a34c4e1af6aa2e7dbf2cb59bc4ae28d9b85 /docs
parentd311efd9d6ddc620f5960c6fc10f25daa628df6c (diff)
Fix broken links in User Guide (#7938)
* Fix broken links in User Guide * Fix link text with filename, use title
Diffstat (limited to 'docs')
-rw-r--r--docs/user-guide/02-conventional-features.md2
-rw-r--r--docs/user-guide/06-interfaces-generics.md2
-rw-r--r--docs/user-guide/08-compiling.md2
-rw-r--r--docs/user-guide/09-reflection.md4
-rw-r--r--docs/user-guide/10-link-time-specialization.md2
-rw-r--r--docs/user-guide/a2-01-spirv-target-specific.md2
6 files changed, 7 insertions, 7 deletions
diff --git a/docs/user-guide/02-conventional-features.md b/docs/user-guide/02-conventional-features.md
index 2571712ee..4f381f62f 100644
--- a/docs/user-guide/02-conventional-features.md
+++ b/docs/user-guide/02-conventional-features.md
@@ -521,7 +521,7 @@ Variadic macros are supported by the Slang preprocessor.
> #### Note ####
> The use of `#include` in new code is discouraged as this functionality has
> been superseded by the module system, please refer to
-> [./04-modules-and-access-control.md](./04-modules-and-access-control.md)
+> [Modules and Access Control](04-modules-and-access-control.md)
Attributes
----------
diff --git a/docs/user-guide/06-interfaces-generics.md b/docs/user-guide/06-interfaces-generics.md
index 7c957f685..30efbada1 100644
--- a/docs/user-guide/06-interfaces-generics.md
+++ b/docs/user-guide/06-interfaces-generics.md
@@ -852,7 +852,7 @@ void main()
}
```
-See [if-let syntax](03-convenience-features.html#if_let-syntax) for more details.
+See [if-let syntax](03-convenience-features.md#if_let-syntax) for more details.
Generic Interfaces
diff --git a/docs/user-guide/08-compiling.md b/docs/user-guide/08-compiling.md
index 3f895a8c3..132002e90 100644
--- a/docs/user-guide/08-compiling.md
+++ b/docs/user-guide/08-compiling.md
@@ -861,7 +861,7 @@ program->link(linkedProgram.writeRef(), diagnosticBlob.writeRef());
```
The linking step is also used to perform link-time specialization, which is a recommended approach for shader specialization
-compared to preprocessor based specialization. Please see [Link-time Specialization and Precompiled Modules](10-link-time-specialization) for more details.
+compared to preprocessor based specialization. Please see [Link-time Specialization and Precompiled Modules](10-link-time-specialization.md) for more details.
Any diagnostic messages related to linking (for example, if an external symbol cannot be resolved) will be written to `diagnosticBlob`.
diff --git a/docs/user-guide/09-reflection.md b/docs/user-guide/09-reflection.md
index ad2047a82..1fc48b3d2 100644
--- a/docs/user-guide/09-reflection.md
+++ b/docs/user-guide/09-reflection.md
@@ -21,14 +21,14 @@ Compiling a Program
-------------------
The first step in reflecting a shader program is, unsurprisingly, to compile it.
-Currently reflection information cannot be queried from code compiled via the command-line `slangc` tool, so applications that want to perform reflection on Slang shader code should use the [compilation API](08-compiling#using-the-compilation-api) to compile a program, and then use `getLayout()` to extract reflection information:
+Currently reflection information cannot be queried from code compiled via the command-line `slangc` tool, so applications that want to perform reflection on Slang shader code should use the [compilation API](08-compiling.md#using-the-compilation-api) to compile a program, and then use `getLayout()` to extract reflection information:
```c++
slang::IComponentType* program = ...;
slang::ProgramLayout* programLayout = program->getLayout(targetIndex);
```
-For more information, see the [relevant section](08-compiling#layout-and-reflection) of the chapter on compilation.
+For more information, see the [relevant section](08-compiling.md#layout-and-reflection) of the chapter on compilation.
Types and Variables
-------------------
diff --git a/docs/user-guide/10-link-time-specialization.md b/docs/user-guide/10-link-time-specialization.md
index eba29076f..b08ef1f0d 100644
--- a/docs/user-guide/10-link-time-specialization.md
+++ b/docs/user-guide/10-link-time-specialization.md
@@ -22,7 +22,7 @@ While functioning systems can be built around preprocessor macros, overusing the
Slang approaches the problem of shader specialization by supporting generics as a first class feature that allow most specializable code to be
written in strongly typed code, and by allowing specialization to be triggered through link-time constants or types.
-As discussed in the [Compiling code with Slang](compiling) chapter, Slang provides a three-step compilation model: precompiling, linking and target code generation.
+As discussed in the [Compiling code with Slang](08-compiling.md) chapter, Slang provides a three-step compilation model: precompiling, linking and target code generation.
Assuming the user shader is implemented as three Slang modules: `a.slang`, `b.slang`, and `c.slang`, the user can precompile all three modules to binary IR and store
them as `a.slang-module`, `b.slang-module`, and `c.slang-module` in a complete offline process that is independent to any specialization arguments.
Next, these three IR modules are linked together to form a self-contained program that will then go through a set of compiler optimizations for target code generation.
diff --git a/docs/user-guide/a2-01-spirv-target-specific.md b/docs/user-guide/a2-01-spirv-target-specific.md
index 7686f7312..05bf023df 100644
--- a/docs/user-guide/a2-01-spirv-target-specific.md
+++ b/docs/user-guide/a2-01-spirv-target-specific.md
@@ -287,7 +287,7 @@ To generate a valid SPIR-V with multiple entry points, use `-fvk-use-entrypoint-
Global memory pointers
------------------------------
-Slang supports global memory pointers when targeting SPIRV. See [an example and explanation](03-convenience-features.html#pointers-limited).
+Slang supports global memory pointers when targeting SPIRV. See [an example and explanation](03-convenience-features.md#pointers-limited).
`float4*` in user code will be translated to a pointer in PhysicalStorageBuffer storage class in SPIRV.
When a slang module uses a pointer type, the resulting SPIRV will be using the SpvAddressingModelPhysicalStorageBuffer64 addressing mode. Modules without use of pointers will use SpvAddressingModelLogical addressing mode.