Documentation: fix typos and grammar (#3945)

3 files changed, 11 insertions, 11 deletions

diff --git a/docs/user-guide/01-get-started.md b/docs/user-guide/01-get-started.md
index a7cf2ddf1..7868b4221 100644
--- a/docs/user-guide/01-get-started.md
+++ b/docs/user-guide/01-get-started.md
@@ -95,7 +95,7 @@ void main()
 
 As you can see, things are being translated just as expected to GLSL: the HLSL `StructuredBuffer` and `RWStructuredBuffer` types are mapped to shader storage objects and the `[numthreads]` attribute are translated into proper `layout(...) in` qualifier on the `main` entry-point.
 
-Note that in the generated GLSL code, all shader parameters are qualified with explicit binding layouts. This is because Slang provides a guarantee that all parameters will have fixed bindings regardless of shader optimization. Without generating explicit binding layout qualifiers, the downstream compiler in the driver may change the binding of a parameter depending on whether any preceding parameters are eliminated during optimization passes. In practice this causes a pain in application code, where developers will need to rely on run-time reflection to determine the binding location of a compiled shader kernel. The issue gets harder to manage when the application also needs to deal with shader specializations. Since Slang will always generate explicit binding locations in its output on all targets as if no parameters are eliminated, the user is assured that parameters always gets a deterministic binding location without having to write any manual binding qualifiers in the Slang code themselves. In fact, we strongly encourage users not to qualify their Slang code with explicit binding qualifiers and let the Slang compiler does its work to properly layout parameters. This is best practice to maintain code modularity and avoid potential binding location conflicts between different shader modules.
+Note that in the generated GLSL code, all shader parameters are qualified with explicit binding layouts. This is because Slang provides a guarantee that all parameters will have fixed bindings regardless of shader optimization. Without generating explicit binding layout qualifiers, the downstream compiler in the driver may change the binding of a parameter depending on whether any preceding parameters are eliminated during optimization passes. In practice this causes a pain in application code, where developers will need to rely on run-time reflection to determine the binding location of a compiled shader kernel. The issue gets harder to manage when the application also needs to deal with shader specializations. Since Slang will always generate explicit binding locations in its output on all targets as if no parameters are eliminated, the user is assured that parameters always gets a deterministic binding location without having to write any manual binding qualifiers in the Slang code themselves. In fact, we strongly encourage users not to qualify their Slang code with explicit binding qualifiers and let the Slang compiler do its work to properly lay out parameters. This is best practice to maintain code modularity and avoid potential binding location conflicts between different shader modules.
 
 ## The full example
 
diff --git a/docs/user-guide/02-conventional-features.md b/docs/user-guide/02-conventional-features.md
index ace4ef6a8..933b19357 100644
--- a/docs/user-guide/02-conventional-features.md
+++ b/docs/user-guide/02-conventional-features.md
@@ -198,7 +198,7 @@ enum Channel : uint16_t
 }
 ```
 
-By default, the underlying type of an enumeration type is `int`. Enumeration types are implicitly convertible to its underlying type. All enumeration types conform to the builtin `ILogical` interface, which provides operator overloads for bit operations. The following code is allowed:
+By default, the underlying type of an enumeration type is `int`. Enumeration types are implicitly convertible to their underlying type. All enumeration types conform to the builtin `ILogical` interface, which provides operator overloads for bit operations. The following code is allowed:
 
 ```csharp
 void test()
@@ -329,7 +329,7 @@ Slang supports the following expression forms with nearly identical syntax to HL
 > #### Note ####
 > Like HLSL but unlike most other C-family languages, the `&&` and `||` operators do *not* currently perform "short-circuiting". 
 > they evaluate all of their operands unconditionally.
-> However, the `?:` operator do perform short-circuiting if the condition is a scalar. Use of `?:` where the condition is a vector is deprecated in Slang. The vector version of `?:` operator does *not* perform short-circuiting, and the user is advised to call `select` instead.
+> However, the `?:` operator does perform short-circuiting if the condition is a scalar. Use of `?:` where the condition is a vector is deprecated in Slang. The vector version of `?:` operator does *not* perform short-circuiting, and the user is advised to call `select` instead.
 > The default behavior of these operators is likely to change in a future Slang release.
 
 Additional expression forms specific to shading languages follow.
@@ -575,7 +575,7 @@ A single parameter may use both the D3D-style and Vulkan-style markup, but in ea
 > #### Note ####
 > Explicit binding markup is tedious to write and error-prone to maintain.
 > It is almost never required in Slang codebases.
-> The Slang compiler can automatically synthesize bindings in a completely deterministic fashion and in most cases the bindings it generates are the as what a programmer would have written manually.
+> The Slang compiler can automatically synthesize bindings in a completely deterministic fashion and in most cases the bindings it generates are what a programmer would have written manually.
 
 Shader Entry Points
 -------------------
@@ -641,7 +641,7 @@ Some system-defined binding semantics may only be available on specific targets
 
 > #### Note ####
 > Instead of using ordinary function parameters with system-defined binding semantics, GLSL uses special system-defined global variables with the `gl_` name prefix.
-> Some recent HLSL features has introduced special globally-defined functions that behave similarly to these `gl_` globals.
+> Some recent HLSL features have introduced special globally-defined functions that behave similarly to these `gl_` globals.
 
 #### User-Defined Binding Semantics
 
diff --git a/docs/user-guide/03-convenience-features.md b/docs/user-guide/03-convenience-features.md
index a325f64f3..e4732436e 100644
--- a/docs/user-guide/03-convenience-features.md
+++ b/docs/user-guide/03-convenience-features.md
@@ -13,7 +13,7 @@ Slang supports automatic variable type inference:
 var a = 1; // OK, `a` is an `int`.
 var b = float3(0, 1, 2); // OK, `b` is a `float3`.
 ```
-Automatic type inference require an initialization expression to present. Without an initial value, the compiler is not able to infer the type of the variable. The following code will result a compiler error:
+Automatic type inference require an initialization expression to present. Without an initial value, the compiler is not able to infer the type of the variable. The following code will result in a compiler error:
 ```csharp
 var a; // Error, cannot infer the type of `a`.
 ```
@@ -25,7 +25,7 @@ var b : int; // OK.
 ```
 
 ## Immutable Values
-The `var` syntax and the traditional C-style variable definition introduces a _mutable_ variable whose value can be changed after its definition. If you wish to introduce an immutable or constant value, you may use the `let` keyword:
+The `var` syntax and the traditional C-style variable definition introduce a _mutable_ variable whose value can be changed after its definition. If you wish to introduce an immutable or constant value, you may use the `let` keyword:
 ```rust
 let a = 5; // OK, `a` is `int`.
 let b : int = 5; // OK.
@@ -68,7 +68,7 @@ namespace ns1
 }
 ```
 
-To access symbols defined in a namespace, you can use its qualified name with namespace prefixes:
+To access symbols defined in a namespace, you can use their qualified name with namespace prefixes:
 ```csharp
 void test()
 {
@@ -218,7 +218,7 @@ property uint highBits
 
 ## Initializers
 > #### Note ####
-> The syntax for defining initializers are subject to future change.
+> The syntax for defining initializers is subject to future change.
 
 
 Slang supports defining initializers in `struct` types. You can write:
@@ -415,7 +415,7 @@ If a base type is marked as `[sealed]`, then inheritance from the type is not al
 
 ### Limitations
 
-Please note that the support for inheritance is currently very limited. Common features that comes with inheritance, such as `virtual` functions and multiple inheritance are not supported by the Slang compiler. Implicit down-casting to the base type and use the result as a `mutable` argument in a function call is also not supported.
+Please note that the support for inheritance is currently very limited. Common features that come with inheritance, such as `virtual` functions and multiple inheritance are not supported by the Slang compiler. Implicit down-casting to the base type and use the result as a `mutable` argument in a function call is also not supported.
 
 Extensions
 --------------------
@@ -450,7 +450,7 @@ void test()
 This feature is similar to extensions in Swift and partial classes in C#.
 
 > #### Note:
-> You can only extend a type with additional methods. Extending with additiional data fields is not allowed.
+> You can only extend a type with additional methods. Extending with additional data fields is not allowed.
 
 Multi-level break
 -------------------