17 files changed, 41 insertions, 41 deletions

diff --git a/docs/user-guide/00-introduction.md b/docs/user-guide/00-introduction.md
index 6bc64dd36..023256b9c 100644
--- a/docs/user-guide/00-introduction.md
+++ b/docs/user-guide/00-introduction.md
@@ -66,7 +66,7 @@ Who is this guide for?
 ----------------------
 
 The content of this guide is written for real-time graphics programmers with a moderate or higher experience level.
-It assumes the reader has previously used a real-time shading langauge like HLSL, GLSL, or MetalSL together with an API like Direct3D 11/12, Vulkan, or Metal.
+It assumes the reader has previously used a real-time shading language like HLSL, GLSL, or MetalSL together with an API like Direct3D 11/12, Vulkan, or Metal.
 We also assume that the reader is familiar enough with C/C++ to understand code examples and API signatures in those languages.
 
 If you are new to programming entirely, this guide is unlikely to be helpful.
diff --git a/docs/user-guide/02-conventional-features.md b/docs/user-guide/02-conventional-features.md
index 9e2743aa3..6973cbef1 100644
--- a/docs/user-guide/02-conventional-features.md
+++ b/docs/user-guide/02-conventional-features.md
@@ -123,7 +123,7 @@ void f( int b[] )
 
 It is allowed to pass a sized array as argument to an unsized array parameter when calling a function.
 
-Array types has a `getCount()` memeber function that returns the length of the array.
+Array types has a `getCount()` member function that returns the length of the array.
 
 ```hlsl
 int f( int b[] )
@@ -976,7 +976,7 @@ int a[2] = {1, 2}
 #### Array Of Aggregate's
 
 ```csharp
-// Equivlent to `float3 a[2]; a[0] = {1,2,3}; b[1] = {4,5,6};`
+// Equivalent to `float3 a[2]; a[0] = {1,2,3}; b[1] = {4,5,6};`
 float3 a[2] = { {1,2,3}, {4,5,6} };
 ```
 #### Flattened Array Initializer
@@ -1050,7 +1050,7 @@ struct GenerateCtor1 : GenerateCtorInner1
 GenerateCtor1 val[2] = { { 3 }, { 2 } };
 ```
 
-In addition, Slang also provides compatbility support for C-style initializer lists with `struct`s. C-style initializer lists can use [Partial Initializer List's](#Partial-Initializer-List's) and [Flattened Array Initializer With Struct's](#Flattened-Array-Initializer-With-Struct)
+In addition, Slang also provides compatibility support for C-style initializer lists with `struct`s. C-style initializer lists can use [Partial Initializer List's](#Partial-Initializer-List's) and [Flattened Array Initializer With Struct's](#Flattened-Array-Initializer-With-Struct)
 
 A struct is considered a C-style struct if:
 1. User never defines a custom constructor with **more than** 0 parameters
@@ -1109,7 +1109,7 @@ float3 val2 = {};
 
 #### Struct Type
 
-1. Atempt to call default constructor (`__init()`) of a `struct`
+1. Attempt to call default constructor (`__init()`) of a `struct`
 
 
 ```csharp
diff --git a/docs/user-guide/03-convenience-features.md b/docs/user-guide/03-convenience-features.md
index 65357ce1a..aeec8eb28 100644
--- a/docs/user-guide/03-convenience-features.md
+++ b/docs/user-guide/03-convenience-features.md
@@ -672,7 +672,7 @@ struct MaxValueAttribute
 uniform int scaleFactor;
 ```
 
-In the above code, the `MaxValueAttribute` struct type is decorated with the `[__AttributeUsage]` attribute, which informs that `MaxValueAttribute` type should be interpreted as a definiton for a user-defined attribute, `[MaxValue]`, that can be used to decorate all variables or fields. The members of the struct defines the argument list for the attribute.
+In the above code, the `MaxValueAttribute` struct type is decorated with the `[__AttributeUsage]` attribute, which informs that `MaxValueAttribute` type should be interpreted as a definition for a user-defined attribute, `[MaxValue]`, that can be used to decorate all variables or fields. The members of the struct defines the argument list for the attribute.
 
 The `scaleFactor` uniform parameter is declared with the user defined `[MaxValue]` attribute, providing two arguments for `value` and `description`.
 
diff --git a/docs/user-guide/05-capabilities.md b/docs/user-guide/05-capabilities.md
index 8f377f5a4..6426cb37c 100644
--- a/docs/user-guide/05-capabilities.md
+++ b/docs/user-guide/05-capabilities.md
@@ -92,7 +92,7 @@ public void myFunc()
 }
 ```
 
-## Inferrence of Capability Requirements
+## Inference of Capability Requirements
 
 By default, Slang will infer the capability requirements of a function given its definition, as long as the function has `internal` or `private` visibility. For example, given:
 ```csharp
@@ -110,7 +110,7 @@ Slang will automatically deduce that `myFunc` has capability
 ```
 Since `discard` statement requires capability `fragment`.
 
-## Inferrence on target_switch
+## Inference on target_switch
 
 A `__target_switch` statement will introduce disjunctions in its inferred capability requirement. For example:
 ```csharp
diff --git a/docs/user-guide/06-interfaces-generics.md b/docs/user-guide/06-interfaces-generics.md
index 3d35d2bf5..7a4248442 100644
--- a/docs/user-guide/06-interfaces-generics.md
+++ b/docs/user-guide/06-interfaces-generics.md
@@ -464,7 +464,7 @@ struct ArrayFloatContainer
 ```
 Because C++ does not require a template function to define _constraints_ on the templated type, there are no interfaces or inheritances involved in the definition of `ArrayFloatContainer`. However `ArrayFloatContainer` still needs to define what its `Iterator` type is, so the `sum` function can be successfully specialized with an `ArrayFloatContainer`.
 
-Note that the biggest difference between C++ templates and generics is that templates are not type-checked prior to specialization, and therefore the code that consumes a templated type (`TContainer` in this example) can simply assume `container` has a method named `getElementAt`, and the `TContainer` scope provides a type definition for `TContainer::Iterator`. Compiler error only arises when the programmer is attempting to specialize the `sum` function with a type that does not meet these assumptions. Contrarily, Slang requires all possible uses of a generic type be declared through an interface. By stating that `TContainer:IContainer` in the generics declaration, the Slang compiler can verify that `container.getElementAt` is calling a valid function. Similarily, the interface also tells the compiler that `TContainer.Iterator` is a valid type and enables the compiler to fully type check the `sum` function without specializing it first.
+Note that the biggest difference between C++ templates and generics is that templates are not type-checked prior to specialization, and therefore the code that consumes a templated type (`TContainer` in this example) can simply assume `container` has a method named `getElementAt`, and the `TContainer` scope provides a type definition for `TContainer::Iterator`. Compiler error only arises when the programmer is attempting to specialize the `sum` function with a type that does not meet these assumptions. Contrarily, Slang requires all possible uses of a generic type be declared through an interface. By stating that `TContainer:IContainer` in the generics declaration, the Slang compiler can verify that `container.getElementAt` is calling a valid function. Similarly, the interface also tells the compiler that `TContainer.Iterator` is a valid type and enables the compiler to fully type check the `sum` function without specializing it first.
 
 ### Similarity to Swift and Rust
 
diff --git a/docs/user-guide/07-autodiff.md b/docs/user-guide/07-autodiff.md
index 9fc5205e7..0664d2499 100644
--- a/docs/user-guide/07-autodiff.md
+++ b/docs/user-guide/07-autodiff.md
@@ -501,7 +501,7 @@ The following built-in functions are backward differentiable and both their forw
 
 ## Primal Substitute Functions
 
-Sometimes it is desirable to replace a function with another when generating forward or backward derivative propagation code. For example, the following code shows a function that computes the integral of some term by sampling and we want to use a different sampling stragegy when computing the derivatives.
+Sometimes it is desirable to replace a function with another when generating forward or backward derivative propagation code. For example, the following code shows a function that computes the integral of some term by sampling and we want to use a different sampling strategy when computing the derivatives.
 ```csharp
 float myTerm(float x)
 {
@@ -535,7 +535,7 @@ float getSampleForDerivativeComputation(float a, float b)
 
 Here, the `[PrimalSubstituteOf(getSample)]` attributes marks the `getSampleForDerivativeComputation` function as the substitute for `getSample` in derivative propagation functions. When a function has a primal substitute, the compiler will treat all calls to that function as if it is a call to the substitute function when generating derivative code. Note that this only applies to compiler generated derivative function and does not affect user provided derivative functions. If a user provided derivative function calls `getSample`, it will not be replaced by `getSampleForDerivativeComputation` by the compiler.
 
-Similar to `[ForwardDerivative]` and `[ForwardDerivativeOf]` attributes, The `[PrimalSubsitute(substFunc)]` attribute works the other way around: it specifies the primal substitute function of the function being marked.
+Similar to `[ForwardDerivative]` and `[ForwardDerivativeOf]` attributes, The `[PrimalSubstitute(substFunc)]` attribute works the other way around: it specifies the primal substitute function of the function being marked.
 
 Primal substitute can be used as another way to make a function differentiable. A function is considered differentiable if it has a primal substitute that is differentiable. The following code illustrates this mechanism.
 ```csharp
diff --git a/docs/user-guide/08-compiling.md b/docs/user-guide/08-compiling.md
index 23a33d914..765dba5a5 100644
--- a/docs/user-guide/08-compiling.md
+++ b/docs/user-guide/08-compiling.md
@@ -956,7 +956,7 @@ meanings of their `CompilerOptionValue` encodings.
 | VulkanUseGLLayout | When set, will use std430 layout instead of D3D buffer layout for raw buffer load/stores. `intValue0` specifies a bool value for the setting. |
 | VulkanEmitReflection | Specifies the `-fspv-reflect` option. When set will include additional reflection instructions in the output SPIRV. `intValue0` specifies a bool value for the setting. |
 | GLSLForceScalarLayout | Specifies the `-force-glsl-scalar-layout` option. When set will use `scalar` layout for all buffers when generating SPIRV. `intValue0` specifies a bool value for the setting. |
-| EnableEffectAnnotations | When set will turn on compatibilty mode to parse legacy HLSL effect annoation syntax. `intValue0` specifies a bool value for the setting. |
+| EnableEffectAnnotations | When set will turn on compatibility mode to parse legacy HLSL effect annotation syntax. `intValue0` specifies a bool value for the setting. |
 | EmitSpirvViaGLSL | When set will emit SPIRV by emitting GLSL first and then use glslang to produce the final SPIRV code. `intValue0` specifies a bool value for the setting. |
 | EmitSpirvDirectly | When set will use Slang's direct-to-SPIRV backend to generate SPIRV directly from Slang IR. `intValue0` specifies a bool value for the setting. |
 | SPIRVCoreGrammarJSON | When set will use the provided SPIRV grammar file to parse SPIRV assembly blocks. `stringValue0` specifies a path to the spirv core grammar json file. |
diff --git a/docs/user-guide/09-reflection.md b/docs/user-guide/09-reflection.md
index ff874fb5f..4e810fd1f 100644
--- a/docs/user-guide/09-reflection.md
+++ b/docs/user-guide/09-reflection.md
@@ -137,7 +137,7 @@ If you have a type layout with kind `Array` you can query information about the
 ```c++
 size_t arrayElementCount = typeLayout->getElementCount();
 slang::TypeLayoutReflection* elementTypeLayout = typeLayout->getElementTypeLayout();
-sie_t arrayElementStride = typeLayout->getElementStride(category);
+size_t arrayElementStride = typeLayout->getElementStride(category);
 ```
 
 An array of unknown size will currently report zero elements.
@@ -196,7 +196,7 @@ In the case of a compute shader entry point, you can also query the user-specifi
 
 ```c++
 SlangUInt threadGroupSize[3];
-entryPoint->getComputeThreadGruopSize(3, &threadGroupSize[0]);
+entryPoint->getComputeThreadGroupSize(3, &threadGroupSize[0]);
 ```
 
 ## Function Reflection
diff --git a/docs/user-guide/09-targets.md b/docs/user-guide/09-targets.md
index f3f146625..4f25aa600 100644
--- a/docs/user-guide/09-targets.md
+++ b/docs/user-guide/09-targets.md
@@ -129,9 +129,9 @@ The D3D11 rasterization pipeline can include up to five programmable stages, alt
 Shader parameters are passed to each D3D11 stage via slots.
 Each stage has its own slots of the following types:
 
-- **Constant buffers** are used for passing relatively small (4KB or less) amounts of data that will be read by GPU code. Constant bufers are passed via `b` registers.
+- **Constant buffers** are used for passing relatively small (4KB or less) amounts of data that will be read by GPU code. Constant buffers are passed via `b` registers.
 
-- **Shader resource views** (SRVs) include most textures, buffers, and other opaque resource types thare are read or sampled by GPU code. SRVs use `t` registers.
+- **Shader resource views** (SRVs) include most textures, buffers, and other opaque resource types there are read or sampled by GPU code. SRVs use `t` registers.
 
 - **Unordered access views** (UAVs) include textures, buffers, and other opaque resource types used for write or read-write operations in GPU code. UAVs use `u` registers.
 
@@ -221,7 +221,7 @@ A D3D12 pipeline layout can specify that certain root parameters or certain slot
 The D3D12 ray tracing pipeline adds a new mechanism for passing shader parameters.
 In addition to allowing shader parameters to be passed to the entire pipeline via root parameters, each shader table entry provides storage space for passing argument data specific to that entry.
 
-Similar to the use of a pipline layout (root signature) to configure the use of root parameters, each kernel used within shader entries must be configured with a "local root signature" that defines how the storage space in the shader table entry is to be used.
+Similar to the use of a pipeline layout (root signature) to configure the use of root parameters, each kernel used within shader entries must be configured with a "local root signature" that defines how the storage space in the shader table entry is to be used.
 Shader parameters are still bound to registers and spaces as for non-ray-tracing code, and the local root signature simply allows those same registers/spaces to be associated with locations in a shader table entry.
 
 One important detail is that some shader table entries are associated with a kernel for a single stage (e.g., a single miss shader), while other shader table entries are associated with a "hit group" consisting of up to one each of an intersection, any-hit, and closest-hit kernel.
diff --git a/docs/user-guide/10-link-time-specialization.md b/docs/user-guide/10-link-time-specialization.md
index 4541a6f55..14b10c63e 100644
--- a/docs/user-guide/10-link-time-specialization.md
+++ b/docs/user-guide/10-link-time-specialization.md
@@ -5,7 +5,7 @@ permalink: /user-guide/link-time-specialization
 
 # Link-time Specialization and Module Precompilation
 
-Traditionally, graphics developers have been relying on the preprocesor defines to specialize their shader code for high-performance GPU execution.
+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.
   This means that the compiler must redo almost all work from the scratch with every specialized variant, including parsing, type checking, IR generation
diff --git a/docs/user-guide/a1-01-matrix-layout.md b/docs/user-guide/a1-01-matrix-layout.md
index 3a9921db8..cb301ce8f 100644
--- a/docs/user-guide/a1-01-matrix-layout.md
+++ b/docs/user-guide/a1-01-matrix-layout.md
@@ -24,14 +24,14 @@ Two conventions of matrix transform math
 
 Depending on the platform a developer is used to, a matrix-vector transform can be expressed as either `v*m` (`mul(v, m)` in HLSL), or `m*v` (`mul(m,v)` in HLSL). This convention, together with the matrix layout (column-major or row-major), determines how a matrix should be filled out in host code. 
 
-In HLSL/Slang the order of vector and matrix parameters to `mul` determine how the *vector* is interpretted. This interpretation is required because a vector does not in as of it's self differentiate between being a row or a column. 
+In HLSL/Slang the order of vector and matrix parameters to `mul` determine how the *vector* is interpreted. This interpretation is required because a vector does not in as of it's self differentiate between being a row or a column.
 
-* `mul(v, m)` - v is interpretted as a row vector 
-* `mul(m, v)` - v is interpretted as a column vector. 
+* `mul(v, m)` - v is interpreted as a row vector.
+* `mul(m, v)` - v is interpreted as a column vector.
 
 Through this mechanism a developer is able to write transforms in their preferred style. 
 
-These two styles are not directly interchangable - for a given `v` and `m` then generally `mul(v, m) != mul(m, v)`. For that the matrix needs to be transposed so 
+These two styles are not directly interchangeable - for a given `v` and `m` then generally `mul(v, m) != mul(m, v)`. For that the matrix needs to be transposed so
 
 * `mul(v, m) == mul(transpose(m), v)`
 * `mul(m, v) == mul(v, transpose(m))`
@@ -42,7 +42,7 @@ This behavior is *independent* of how a matrix layout in memory. Host code needs
 
 Another way to think about this difference is in terms of where translation terms should be placed in memory when filling a typical 4x4 transform matrix. When transforming a row vector (ie `mul(v, m)`) with a `row-major` matrix layout, translation will be at `m + 12, 13, 14`. For a `column-major` matrix layout, translation will be at `m + 3, 7, 11`.
 
-Note it is a *HLSL*/*Slang* convention that the parameter ordering of `mul(v, m)` means v is a *row* vector. A host maths library *could* have a transform function `SomeLib::transform(v, m)` such that `v` is a interpretted as *column* vector. For simplicitys sake the remainder of this discussion assumes that the `mul(v, m)` in equivalent in host code follows the interpretation that `v` is *row* vector.
+Note it is a *HLSL*/*Slang* convention that the parameter ordering of `mul(v, m)` means v is a *row* vector. A host maths library *could* have a transform function `SomeLib::transform(v, m)` such that `v` is a interpreted as *column* vector. For simplicitys sake the remainder of this discussion assumes that the `mul(v, m)` in equivalent in host code follows the interpretation that `v` is *row* vector.
 
 Discussion
 ----------
@@ -64,7 +64,7 @@ If we accept 2, then there are only two possible combinations - either both host
 
 This is simple, but is perhaps not the end of the story. First lets assume that we want our Slang code to be as portable as possible. As previously discussed for CUDA and C++/CPU targets Slang ignores the matrix layout settings - the matrix layout is *always* `row-major`.
 
-Second lets consider performance. The matrix layout in a host maths libray is not arbitrary from a performance point of view. A performant host maths library will want to use SIMD instructions. With both x86/x64 SSE and ARM NEON SIMD it makes a performance difference which layout is used, depending on if `column` or `row` is the *prefered* vector interpretation. If the `row` vector interpretation is prefered, it is most performant to have `row-major` matrix layout. Conversely if `column` vector interpretation is prefered `column-major` matrix will be the most performant.
+Second lets consider performance. The matrix layout in a host maths library is not arbitrary from a performance point of view. A performant host maths library will want to use SIMD instructions. With both x86/x64 SSE and ARM NEON SIMD it makes a performance difference which layout is used, depending on if `column` or `row` is the *preferred* vector interpretation. If the `row` vector interpretation is preferred, it is most performant to have `row-major` matrix layout. Conversely if `column` vector interpretation is preferred `column-major` matrix will be the most performant.
 
 The performance difference comes down to a SIMD implementation having to do a transpose if the layout doesn't match the preferred vector interpretation. 
 
@@ -78,7 +78,7 @@ The only combination that fulfills all aspects is `row-major` matrix layout and
 
 It's worth noting that for targets that honor the default matrix layout - that setting can act like a toggle transposing a matrix layout. If for some reason the combination of choices leads to inconsistent vector transforms, an implementation can perform this transform in *host* code at the boundary between host and the kernel. This is not the most performant or convenient scenario, but if supported in an implementation it could be used for targets that do not support kernel matrix layout settings. 
 
-If only targetting platforms that honor matrix layout, there is more flexibility, our constraints are 
+If only targeting platforms that honor matrix layout, there is more flexibility, our constraints are
 
 1) Consistency : Same vector interpretation in shader and host code
 2) Performance: Host vector interpretation should match host matrix layout
@@ -88,7 +88,7 @@ Then there are two combinations that work
 1) `row-major` matrix layout for host and kernel, and `row` vector interpretation.
 2) `column-major` matrix layout for host and kernel, and `column` vector interpretation.
 
-If the host maths library is not performance orientated, it may be arbitray from a performance point of view if a `row` or `column` vector interpretation is used. In that case assuming shader and host vector interpretation is the same it is only important that the kernel and maths library matrix layout match. 
+If the host maths library is not performance orientated, it may be arbitrary from a performance point of view if a `row` or `column` vector interpretation is used. In that case assuming shader and host vector interpretation is the same it is only important that the kernel and maths library matrix layout match.
 
 Another way of thinking about these combinations is to think of each change in `row-major`/`column-major` matrix layout and `row`/`column` vector interpretation is a transpose. If there are an *even* number of flips then all the transposes cancel out. Therefore the following combinations work
 
diff --git a/docs/user-guide/a1-02-slangpy.md b/docs/user-guide/a1-02-slangpy.md
index f00ca0a14..8a9828557 100644
--- a/docs/user-guide/a1-02-slangpy.md
+++ b/docs/user-guide/a1-02-slangpy.md
@@ -308,7 +308,7 @@ float computeOutputPixel(TensorView<float> input, uint2 pixelLoc)
         }
     }
 
-    // Comptue the average value.
+    // Compute the average value.
     sumValue /= count;
 
     return sumValue;
@@ -390,7 +390,7 @@ float computeOutputPixel(
         }
     }
 
-    // Comptue the average value.
+    // Compute the average value.
     sumValue /= count;
 
     return sumValue;
@@ -494,7 +494,7 @@ TorchTensor<float> square(TorchTensor<float> input)
 ```
 
 Here, we mark the function with the `[TorchEntryPoint]` attribute, so it will be compiled to C++ and exported as a python callable. 
-Since this is a host function, we can perform tensor allocations. For instnace, `square()` calls `TorchTensor<float>.zerosLike` to allocate a 2D-tensor that has the same size as the input.
+Since this is a host function, we can perform tensor allocations. For instance, `square()` calls `TorchTensor<float>.zerosLike` to allocate a 2D-tensor that has the same size as the input.
 `zerosLike` returns a `TorchTensor<float>` object that represents a CPU handle of a PyTorch tensor.
 
 Then we launch `square_kernel` with the `__dispatch_kernel` syntax. Note that we can directly pass
@@ -729,7 +729,7 @@ Marks a function for export to Python. Functions marked with `[TorchEntryPoint]`
 Marks a function as a CUDA device function, and ensures the compiler to include it in the generated CUDA source.
 
 #### `[AutoPyBindCUDA]` attribute
-Markes a cuda kernel for automatic binding generation so that it may be invoked from python without having to hand-code the torch entry point. The marked function **must** also be marked with `[CudaKernel]`. If the marked function is also marked with `[Differentiable]`, this will also generate bindings for the derivative methods.
+Marks a cuda kernel for automatic binding generation so that it may be invoked from python without having to hand-code the torch entry point. The marked function **must** also be marked with `[CudaKernel]`. If the marked function is also marked with `[Differentiable]`, this will also generate bindings for the derivative methods.
 
 Restriction: methods marked with `[AutoPyBindCUDA]` will not operate 
 
diff --git a/docs/user-guide/a1-05-uniformity.md b/docs/user-guide/a1-05-uniformity.md
index 630dfb802..be07f89c0 100644
--- a/docs/user-guide/a1-05-uniformity.md
+++ b/docs/user-guide/a1-05-uniformity.md
@@ -5,13 +5,13 @@ layout: user-guide
 Uniformity Analysis
 ===========
 
-On certain hardwares, accessing resources with a non-uniform index may lead to significant performance degradation. Developers can often benefit from a compiler warning for unintentional non-uniform resource access.
+On certain hardware, accessing resources with a non-uniform index may lead to significant performance degradation. Developers can often benefit from a compiler warning for unintentional non-uniform resource access.
 
 Starting from v2024.1.0, Slang provides uniformity analysis that can warn users if a non-dynamically-uniform value is being used unintentionally. This feature is not enabled by default but can be turned on with the `-validate-uniformity` commandline option when using `slangc`, or the `CompilerOptionName::ValidateUniformity` compiler option when using the API.
 
 In addition to specifying the compiler option, the source code must be augmented with the `dynamic_uniform` modifier to mark function parameters, struct fields or local variables as expecting a dynamic uniform value.
 
-For example, the following code will triger a warning:
+For example, the following code will trigger a warning:
 ```csharp
 // Indicate that the `v` parameter needs to be dynamic uniform.
 float f(dynamic_uniform float v)
@@ -101,4 +101,4 @@ void main()
 {
     expectUniform(f()); // Warning.
 }
-```
\ No newline at end of file
+```
diff --git a/docs/user-guide/a2-01-spirv-target-specific.md b/docs/user-guide/a2-01-spirv-target-specific.md
index e96b81162..048318a09 100644
--- a/docs/user-guide/a2-01-spirv-target-specific.md
+++ b/docs/user-guide/a2-01-spirv-target-specific.md
@@ -60,7 +60,7 @@ The system-value semantics are translated to the following SPIR-V code.
 | `SV_SampleIndex`              | `BuiltIn SampleId`                |
 | `SV_ShadingRate`              | `BuiltIn PrimitiveShadingRateKHR` |
 | `SV_StartVertexLocation`      | `*Not supported*                  |
-| `SV_StartInstanceLocation`    | `*Not suported*                   |
+| `SV_StartInstanceLocation`    | `*Not supported*                  |
 | `SV_StencilRef`               | `BuiltIn FragStencilRefEXT`       |
 | `SV_Target<N>`                | `Location`                        |
 | `SV_TessFactor`               | `BuiltIn TessLevelOuter`          |
@@ -139,7 +139,7 @@ StructuredBuffer and ByteAddressBuffer are translated to a shader storage buffer
 RWStructuredBuffer and RWByteAddressBuffer are translated to a shader storage buffer with `read-write` access.
 RasterizerOrderedStructuredBuffer and RasterizerOrderedByteAddressBuffer will use an extension, `SPV_EXT_fragment_shader_interlock`.
 
-If you need to apply a different buffer layout for indivisual `ConstantBuffer` or `StructuredBuffer`, you can specify the layout as a second generic argument. E.g., `ConstantBuffer<T, Std430DataLayout>`, `StructuredBuffer<T, Std140DataLayout>`, `StructuredBuffer<T, Std430DataLayout>` or `StructuredBuffer<T, ScalarDataLayout>`.
+If you need to apply a different buffer layout for individual `ConstantBuffer` or `StructuredBuffer`, you can specify the layout as a second generic argument. E.g., `ConstantBuffer<T, Std430DataLayout>`, `StructuredBuffer<T, Std140DataLayout>`, `StructuredBuffer<T, Std430DataLayout>` or `StructuredBuffer<T, ScalarDataLayout>`.
 
 Note that there are compiler options, "-fvk-use-scalar-layout" / "-force-glsl-scalar-layout" and "-fvk-use-dx-layout".
 These options do the same but they are applied globally.
@@ -153,7 +153,7 @@ In contrast to `ConstantBuffer`, a `ParameterBlock<T>` introduces a new descript
 
 `ParameterBlock` is designed specifically for D3D12/Vulkan/Metal/WebGPU, so that parameters defined in `T` can be placed into an independent descriptor table/descriptor set/argument buffer/binding group.
 
-For example, when targeting Vulkan, when a ParameterBlock doesn't contain nested parameter block fields, it will always map to a single descriptor set, with a dedicated set number and every resources is placed into the set with binding index starting from 0. This allows the user application to create and pre-populate the descriptor set and reuse it during command encoding, without explicilty specifying the binding index for each individual parameter.
+For example, when targeting Vulkan, when a ParameterBlock doesn't contain nested parameter block fields, it will always map to a single descriptor set, with a dedicated set number and every resources is placed into the set with binding index starting from 0. This allows the user application to create and pre-populate the descriptor set and reuse it during command encoding, without explicitly specifying the binding index for each individual parameter.
 
 When both ordinary data fields and resource typed fields exist in a parameter block, all ordinary data fields will be grouped together into a uniform buffer and appear as a binding 0 of the resulting descriptor set.
 
@@ -237,7 +237,7 @@ To generate a valid SPIR-V with multiple entry points, use `-fvk-use-entrypoint-
 Global memory pointers
 ------------------------------
 
-Slang supports global memory pointers when targetting SPIRV. See [an example and explanation](convenience-features.html#pointers-limited).
+Slang supports global memory pointers when targeting SPIRV. See [an example and explanation](convenience-features.html#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.
diff --git a/docs/user-guide/a2-03-wgsl-target-specific.md b/docs/user-guide/a2-03-wgsl-target-specific.md
index 7d1ec87f6..75a2a6da3 100644
--- a/docs/user-guide/a2-03-wgsl-target-specific.md
+++ b/docs/user-guide/a2-03-wgsl-target-specific.md
@@ -43,7 +43,7 @@ The system-value semantics are translated to the following WGSL code.
 | SV_SampleIndex | `@builtin(sample_index)` |
 | SV_ShadingRate | *Not supported* |
 | SV_StartVertexLocation | *Not supported* |
-| SV_StartInstanceLocation | *Not suported* |
+| SV_StartInstanceLocation | *Not supported* |
 | SV_StencilRef | *Not supported* |
 | SV_Target<N> | *Not supported* |
 | SV_TessFactor | *Not supported* |
diff --git a/docs/user-guide/a3-02-reference-capability-atoms.md b/docs/user-guide/a3-02-reference-capability-atoms.md
index 9f673eaf8..e7a9b1bb4 100644
--- a/docs/user-guide/a3-02-reference-capability-atoms.md
+++ b/docs/user-guide/a3-02-reference-capability-atoms.md
@@ -1046,7 +1046,7 @@ Compound Capabilities
 > Capabilities required to use GLSL-style subgroup operations 'subgroup_shuffle'
 
 `subgroup_shufflerelative`
-> Capabilities required to use GLSL-style subgroup operations 'subgroup_shufle_relative'
+> Capabilities required to use GLSL-style subgroup operations 'subgroup_shuffle_relative'
 
 `subgroup_clustered`
 > Capabilities required to use GLSL-style subgroup operations 'subgroup_clustered'
diff --git a/docs/user-guide/toc.html b/docs/user-guide/toc.html
index 6566919c1..7ab3b5b91 100644
--- a/docs/user-guide/toc.html
+++ b/docs/user-guide/toc.html
@@ -65,8 +65,8 @@
 <li data-link="capabilities#capability-atoms-and-capability-requirements"><span>Capability Atoms and Capability Requirements</span></li>
 <li data-link="capabilities#conflicting-capabilities"><span>Conflicting Capabilities</span></li>
 <li data-link="capabilities#requirements-in-parent-scope"><span>Requirements in Parent Scope</span></li>
-<li data-link="capabilities#inferrence-of-capability-requirements"><span>Inferrence of Capability Requirements</span></li>
-<li data-link="capabilities#inferrence-on-target-switch"><span>Inferrence on target_switch</span></li>
+<li data-link="capabilities#inference-of-capability-requirements"><span>Inference of Capability Requirements</span></li>
+<li data-link="capabilities#inference-on-target-switch"><span>Inference on target_switch</span></li>
 <li data-link="capabilities#capability-aliases"><span>Capability Aliases</span></li>
 <li data-link="capabilities#validation-of-capability-requirements"><span>Validation of Capability Requirements</span></li>
 </ul>