10 files changed, 20 insertions, 20 deletions

diff --git a/docs/user-guide/02-conventional-features.md b/docs/user-guide/02-conventional-features.md
index f4d6816db..c59999ce3 100644
--- a/docs/user-guide/02-conventional-features.md
+++ b/docs/user-guide/02-conventional-features.md
@@ -995,7 +995,7 @@ float3 a[3] = {1,2,3, 4,5,6};
 
 ### Initializer Lists - Struct
 
-In most scenarios, using an initializer list to create a struct typed value is equivalent to calling the struct's constructor using the elements in the initilaizer list as arguments for the constructor, for example:
+In most scenarios, using an initializer list to create a struct typed value is equivalent to calling the struct's constructor using the elements in the initializer list as arguments for the constructor, for example:
 ```csharp
 struct GenerateCtorInner1
 {
@@ -1061,7 +1061,7 @@ In addition, Slang also provides compatibility support for C-style initializer l
 
 A struct is considered a C-style struct if:
 1. User never defines a custom constructor with **more than** 0 parameters
-2. All member variables in a `struct` have the same visibiliity (`public` or `internal` or `private`).
+2. All member variables in a `struct` have the same visibility (`public` or `internal` or `private`).
 
 #### Partial Initializer List's
 
diff --git a/docs/user-guide/06-interfaces-generics.md b/docs/user-guide/06-interfaces-generics.md
index 7a4248442..a07ccc6b7 100644
--- a/docs/user-guide/06-interfaces-generics.md
+++ b/docs/user-guide/06-interfaces-generics.md
@@ -429,7 +429,7 @@ struct MultiArrayFloatContainer : IFloatContainer
 }
 ```
 
-In summary, an `asssociatedtype` requirement in an interface is similar to other types of requirements: a method requirement means that an implementation must provide a method matching the interface signature, while an `associatedtype` requirement means that an implementation must provide a type in its scope with the matching name and interface constraint. In general, when defining an interface that is producing and consuming an object whose actual type is implementation-dependent, the type of this object can often be modeled as an associated type in the interface.
+In summary, an `associatedtype` requirement in an interface is similar to other types of requirements: a method requirement means that an implementation must provide a method matching the interface signature, while an `associatedtype` requirement means that an implementation must provide a type in its scope with the matching name and interface constraint. In general, when defining an interface that is producing and consuming an object whose actual type is implementation-dependent, the type of this object can often be modeled as an associated type in the interface.
 
 
 ### Comparing Generics to C++ Templates
@@ -823,7 +823,7 @@ interface IEnumerator<T>
 
 interface IEnumerable<T>
 {
-    assoicatedtype Enumerator : IEnumerator<T>;
+    associatedtype Enumerator : IEnumerator<T>;
     Enumerator getEnumerator();
 }
 ```
diff --git a/docs/user-guide/07-autodiff.md b/docs/user-guide/07-autodiff.md
index 2a766e1c0..11c6677c4 100644
--- a/docs/user-guide/07-autodiff.md
+++ b/docs/user-guide/07-autodiff.md
@@ -381,7 +381,7 @@ struct MyType
 R original(T0 p0, inout T1, p1, T2 p2);
 ```
 
-Sometimes the derivative function needs to be defined in a different module from the original function, or the derivative function cannot be made visible from the original function. In this case, we can use the `[ForwardDerivativeOf(originalFunnc)]` attribute to inform the compiler that `originalFunc` should be treated as a forward-differentiable function, and the current function is the derivative implementation of `originalFunc`. The following code will have the same effect to associate `derivative` and the forward-derivative implementation of `original`:
+Sometimes the derivative function needs to be defined in a different module from the original function, or the derivative function cannot be made visible from the original function. In this case, we can use the `[ForwardDerivativeOf(originalFunc)]` attribute to inform the compiler that `originalFunc` should be treated as a forward-differentiable function, and the current function is the derivative implementation of `originalFunc`. The following code will have the same effect to associate `derivative` and the forward-derivative implementation of `original`:
 
 ```csharp
 R original(T0 p0, inout T1, p1, T2 p2);
@@ -653,7 +653,7 @@ This may lead to unexpected results. For example:
 struct MyType : IDifferentiable
 {
     no_diff float member;
-    float someOtherMemther;
+    float someOtherMember;
 }
 [ForwardDifferentiable]
 float f(float x)
diff --git a/docs/user-guide/08-compiling.md b/docs/user-guide/08-compiling.md
index 765dba5a5..147bc8144 100644
--- a/docs/user-guide/08-compiling.md
+++ b/docs/user-guide/08-compiling.md
@@ -924,7 +924,7 @@ meanings of their `CompilerOptionValue` encodings.
 
 |CompilerOptionName | Description |
 |:------------------ |:----------- |
-| MacroDefine        | Specifies a prepreocessor macro define entry. `stringValue0` encodes macro name, `stringValue1` encodes the macro value.
+| MacroDefine        | Specifies a preprocessor macro define entry. `stringValue0` encodes macro name, `stringValue1` encodes the macro value.
 | Include            | Specifies an additional search path. `stringValue0` encodes the additional path. |
 | Language           | Specifies the input language. `intValue0` encodes a value defined in `SlangSourceLanguage`. |
 | MatrixLayoutColumn | Use column major matrix layout as default. `intValue0` encodes a bool value for the setting. |
@@ -973,5 +973,5 @@ meanings of their `CompilerOptionValue` encodings.
 ## Debugging
 
 Slang's SPIRV backend supports generating debug information using the [NonSemantic Shader DebugInfo Instructions](https://github.com/KhronosGroup/SPIRV-Registry/blob/main/nonsemantic/NonSemantic.Shader.DebugInfo.100.asciidoc).
-To enable debugging information when targing SPIRV, specify the `-emit-spirv-directly` and the `-g2` argument when using `slangc` tool, or set `EmitSpirvDirectly` to `1` and `DebugInformation` to `SLANG_DEBUG_INFO_LEVEL_STANDARD` when using the API.
+To enable debugging information when targeting SPIRV, specify the `-emit-spirv-directly` and the `-g2` argument when using `slangc` tool, or set `EmitSpirvDirectly` to `1` and `DebugInformation` to `SLANG_DEBUG_INFO_LEVEL_STANDARD` when using the API.
 Debugging support has been tested with RenderDoc.
diff --git a/docs/user-guide/09-reflection.md b/docs/user-guide/09-reflection.md
index d6ea47e7d..973019b13 100644
--- a/docs/user-guide/09-reflection.md
+++ b/docs/user-guide/09-reflection.md
@@ -487,7 +487,7 @@ void printSize(
 }
 ```
 
-Note that the size of a type may be *unbounded* for a particluar layout unit; this case is encoded just like the unbounded case for the element count of an array type (`~size_t(0)`).
+Note that the size of a type may be *unbounded* for a particular layout unit; this case is encoded just like the unbounded case for the element count of an array type (`~size_t(0)`).
 
 The layout units used by a particular type layout can be iterated over using `getCategoryCount()` and `getCategoryByIndex()`:
 
@@ -1052,7 +1052,7 @@ That is, the binding information for the implicit constant buffer will be found
 The `ProgramLayout` type has the appealingly-named `getParameterCount` and `getParameterByIndex()` methods, which seem to be the obvious way to navigate the global-scope parameters of a shader.
 However, we recommend *against* using these functions in applications that want to be able to systematically and robustly reflect any possible input shader code.
 
-While the reflection API implementation makes an effort to ensure that the information returned by `getParameterByIndex()` is not incorrect, it is very difficult when using those functions to account for how global-scope parameters might have been grouped into an automatically-introduced constnat buffer or parameter block.
+While the reflection API implementation makes an effort to ensure that the information returned by `getParameterByIndex()` is not incorrect, it is very difficult when using those functions to account for how global-scope parameters might have been grouped into an automatically-introduced constant buffer or parameter block.
 The `getGlobalConstantBufferBinding()` and `getGlobalConstantBufferSize()` methods can be used in some scenarios, but aren't the best way to get the relevant information.
 
 While it would only matter in corner cases, we still recommend that applications use `getGlobalParamsVarLayout()` instead of `getGlobalParamsTypeLayout()`, to account for cases where the global-scope might have offsets applied to it (and also to handle the global scope and entry-point scopes more uniformly).
@@ -1405,13 +1405,13 @@ In contrast, the cumulative of offset of `c.b` in `t` registers is one, and the
 
 Similarly, when calculating the cumulative offsets of variables inside a parameter block (for targets that can allocate each parameter block its own space), it is important not to sum contributions past an enclosing parameter block.
 
-We can account for these subtleties by extending the representation of access paths in our example application to record the node coresponding to the deepest constant buffer or parameter block along the path:
+We can account for these subtleties by extending the representation of access paths in our example application to record the node corresponding to the deepest constant buffer or parameter block along the path:
 
 ```c++
 struct AccessPath
 {
     AccessPathNode* leaf = nullptr;
-    AccessPathNode* deepestConstantBufer = nullptr;
+    AccessPathNode* deepestConstantBuffer = nullptr;
     AccessPathNode* deepestParameterBlock = nullptr;
 };
 ```
@@ -1427,7 +1427,7 @@ case slang::TypeReflection::Kind::ShaderStorageBuffer:
         // ...
 
         AccumulatedOffsets innerAccessPath = accessPath;
-        innerAccessPath.deepestConstantBufer = innerAccessPath.leaf;
+        innerAccessPath.deepestConstantBuffer = innerAccessPath.leaf;
 
         // ...
     }
@@ -1495,7 +1495,7 @@ When a byte offset is being computed, relative offsets will only be summed up to
 
 ```c++
 case slang::ParameterCategory::Uniform:
-    for (auto node = accessPath.leaf; node != accessPath.deepestConstantBufer; node = node->outer)
+    for (auto node = accessPath.leaf; node != accessPath.deepestConstantBuffer; node = node->outer)
     {
         result.offset += node->varLayout->getOffset(layoutUnit);
     }
diff --git a/docs/user-guide/09-targets.md b/docs/user-guide/09-targets.md
index f2ae76718..711d3fa72 100644
--- a/docs/user-guide/09-targets.md
+++ b/docs/user-guide/09-targets.md
@@ -61,7 +61,7 @@ On platforms that provide a CPU-like "flat" memory model with a single virtual a
 Current graphics APIs provide far more complicated and less uniform mechanisms for passing shader parameters.
 
 A high-level language compiler like Slang handles the task of _binding_ each user-defined shader parameter to one or more of the parameter-passing resources defined by a target platform.
-For example, the Slang compiler might bindg a global `Texture2D` parameter called `gDiffuse` to the `t1` register defined by the Direct3D 11 API.
+For example, the Slang compiler might bind a global `Texture2D` parameter called `gDiffuse` to the `t1` register defined by the Direct3D 11 API.
 
 An application is responsible for passing the argument data for a parameter using the using the corresponding platform-specific resource it was bound to.
 For example, an application should set the texture they want to use for `gDiffuse` to the `t1` register using Direct3D 11 API calls.
@@ -173,7 +173,7 @@ The D3D12 rasterization pipeline provides alternative geometry processing stages
 
 - The optional `amplification` stage precedes the mesh stage and is responsible for determining how many mesh shader invocations should be run.
 
-Compared to the D3D11 pipeline without tesselllation (hull and domain shaders), a mesh shader is kind of like a combined/generalized vertex and geometry shader.
+Compared to the D3D11 pipeline without tessellation (hull and domain shaders), a mesh shader is kind of like a combined/generalized vertex and geometry shader.
 
 Compared to the D3D11 pipeline with tessellation, an amplification shader is kind of like a combined/generalized vertex and hull shader, while a mesh shader is kind of like a combined/generalized domain and geometry shader.
 
diff --git a/docs/user-guide/10-link-time-specialization.md b/docs/user-guide/10-link-time-specialization.md
index 14b10c63e..4c8a110bf 100644
--- a/docs/user-guide/10-link-time-specialization.md
+++ b/docs/user-guide/10-link-time-specialization.md
@@ -7,7 +7,7 @@ permalink: /user-guide/link-time-specialization
 
 Traditionally, graphics developers have been relying on the preprocessor defines to specialize their shader code for high-performance GPU execution.
 While functioning systems can be built around preprocessor macros, overusing them leads to many problems:
-- Long compilation time. With preprocessors defines, specialzation happens before parsing, which is a very early stage in the compilation flow.
+- Long compilation time. With preprocessors defines, specialization happens before parsing, which is a very early stage in the compilation flow.
   This means that the compiler must redo almost all work from the scratch with every specialized variant, including parsing, type checking, IR generation
   and optimization, even when two specialized variants only differ in one constant value. The lack of reuse of compiler front-end work between
   different shader specializations contributes a significant portion to long shader compile times.
diff --git a/docs/user-guide/a1-03-obfuscation.md b/docs/user-guide/a1-03-obfuscation.md
index dab216940..d0f10791b 100644
--- a/docs/user-guide/a1-03-obfuscation.md
+++ b/docs/user-guide/a1-03-obfuscation.md
@@ -193,7 +193,7 @@ This method is currently only available on the `ICompileRequest` and not on the
 
 The file system returned is held in memory, and the blob data held in the file system typically shared, so accessing items this way is typically very low overhead. 
 
-The conventions used for the file system representation could best be described as a work in progress, and may change in the future. Internally Slang stores compilation results as a hierarchy of "artifacts". An artifact consists of the main result, plus associated artifacts. An artifact can also be a container which can additionally hold children artifacts. In the current directory structure each artifact is a directory, with the root directory of the `ISlangMultableFileSystem` being the root artifact. 
+The conventions used for the file system representation could best be described as a work in progress, and may change in the future. Internally Slang stores compilation results as a hierarchy of "artifacts". An artifact consists of the main result, plus associated artifacts. An artifact can also be a container which can additionally hold children artifacts. In the current directory structure each artifact is a directory, with the root directory of the `ISlangMutableFileSystem` being the root artifact. 
 
 Given a directory representing an artifact it can contain 2 special directories `children` and `associated`. The `children` directory contains the artifacts that are children of the current directories artifact. Similarly `associated` contains directories for artifacts that are associated with the current artifact.
 
diff --git a/docs/user-guide/a1-04-interop.md b/docs/user-guide/a1-04-interop.md
index a13bb5ca2..21ed40279 100644
--- a/docs/user-guide/a1-04-interop.md
+++ b/docs/user-guide/a1-04-interop.md
@@ -182,7 +182,7 @@ float modf(float x, out float ip)
 }
 ```
 
-Opcodes such as `OpCapbility`, `OpExtension` and type definitions are allowed inside a `spirv_asm` block. These instructions will be deduplicated and inserted into the correct sections defined by the SPIRV specification, for example:
+Opcodes such as `OpCapability`, `OpExtension` and type definitions are allowed inside a `spirv_asm` block. These instructions will be deduplicated and inserted into the correct sections defined by the SPIRV specification, for example:
 ```cpp
 uint4 WaveMatch(T value)
 {
diff --git a/docs/user-guide/a2-01-spirv-target-specific.md b/docs/user-guide/a2-01-spirv-target-specific.md
index d57cc8ce5..dcbe44e96 100644
--- a/docs/user-guide/a2-01-spirv-target-specific.md
+++ b/docs/user-guide/a2-01-spirv-target-specific.md
@@ -291,7 +291,7 @@ Another way to put, Slang treats column as row and row as column when targeting
 
 Due to the swap of row and column in terminology, the matrix multiplication needs to be performed little differently. Slang translates a matrix multiplication, `mul(mat1, mat2)`, to `transpose(mul(transpose(mat2), transpose(mat1)))` when targeting SPIR-V.
 
-Note that the matrix translation explained above is orthogoal to the memory layout of a matrix. The memory layout is related to how CPU places matrix values in the memory and how GPU reads them. It is like how `std140` or `std430` works. DXC by default uses `column_major` memory layout and Slang uses row-major memory layout. For more information about the matrix memory layout, please see [a1-01-matrix-layout](a1-01-matrix-layout.md).
+Note that the matrix translation explained above is orthogonal to the memory layout of a matrix. The memory layout is related to how CPU places matrix values in the memory and how GPU reads them. It is like how `std140` or `std430` works. DXC by default uses `column_major` memory layout and Slang uses row-major memory layout. For more information about the matrix memory layout, please see [a1-01-matrix-layout](a1-01-matrix-layout.md).
 
 
 Legalization