Hotfix/doc typo5 (#2070)

* #include an absolute path didn't work - because paths were taken to always be relative.

* Fix typos in introduction and conventional features.

* Struct inheritance is allowed.
Fix some typos.

3 files changed, 18 insertions, 19 deletions

diff --git a/docs/user-guide/00-introduction.md b/docs/user-guide/00-introduction.md
index bdb68f3d2..b4bf7bb01 100644
--- a/docs/user-guide/00-introduction.md
+++ b/docs/user-guide/00-introduction.md
@@ -11,7 +11,7 @@ Why use Slang?
 --------------
 
 The Slang system helps real-time graphics developers write cleaner and more maintainable GPU code, without sacrificing run-time performance.
-Slang extends the HLSL language with thoughtfully selected features from modern general-purpose langauges that support improved developer productivity and code quality.
+Slang extends the HLSL language with thoughtfully selected features from modern general-purpose languages that support improved developer productivity and code quality.
 These features have been carefully implemented with an understanding of GPU performance.
 
 Some of the benefits of Slang include:
@@ -20,7 +20,7 @@ Some of the benefits of Slang include:
 
 * _Parameter blocks_ allow shader parameters to be grouped by update rate in order to take advantage of Direct3D 12 descriptor tables and Vulkan descriptor sets, without verbose and error-prone per-parameter markup
 
-* _Interfaces_ and _generics_ provide first-class alternative to hacky preprocessor-based or string-pasting shader specialization. Preprocessor hacks can be replaced with a well-understood language feaure already used in Rust, Swift, C#, Java, and more.
+* _Interfaces_ and _generics_ provide first-class alternative to hacky preprocessor-based or string-pasting shader specialization. Preprocessor hacks can be replaced with a well-understood language feature already used in Rust, Swift, C#, Java, and more.
 
 * Slang supports a first class _module_ system, which enables true separate compilation and semantic checking of shader code. 
 
@@ -81,7 +81,7 @@ Goals and Non-Goals
 -------------------
 
 The rest of this guide introduces the services provided by the Slang system and explains how to use them to solve challenges in real-time graphics programming.
-When servics are introduced one after another, it may be hard to glimpse the bigger picture: why these particular services? Why these implementation? Why these APIs?
+When services are introduced one after another, it may be hard to glimpse the bigger picture: why these particular services? Why these implementations? Why these APIs?
 
 Before we dive into actually _using_ Slang, let us step back and highlight some of the key design goals (and non-goals) that motivate the design:
 
@@ -89,7 +89,7 @@ Before we dive into actually _using_ Slang, let us step back and highlight some
 
 * **Productivity**: Modern GPU codebases are large and growing. Productivity in a large codebase is less about _writing_ code quickly, and more about having code that is understandable, maintainable, reusable, and extensible. Language concepts like "modularity" or "separate compilation" are valuable if they foster greater developer productivity.
 
-* **Portability**: Real-time graphics developers need to suport a wide variety of hardware, graphics APIs, and operating systems. These platforms differ greatly in the level of funcationality they provide. Some system hand-wave portability concerns out of existence by enforcing a "lowest common denominator" approach and/or raising their "min spec" to exclude older or less capable platforms; our goals differ greatly. We aspire to keep our "min spec" as low as is practical (e.g., supporting Direct3D 11 and not just Direct3D 12), while also allowing each target to expose its distinguishing capabilities.
+* **Portability**: Real-time graphics developers need to support a wide variety of hardware, graphics APIs, and operating systems. These platforms differ greatly in the level of functionality they provide. Some systems hand-wave portability concerns out of existence by enforcing a "lowest common denominator" approach and/or raising their "min spec" to exclude older or less capable platforms; our goals differ greatly. We aspire to keep our "min spec" as low as is practical (e.g., supporting Direct3D 11 and not just Direct3D 12), while also allowing each target to expose its distinguishing capabilities.
 
 * **Ease of Adoption**: A language feature or service is worthless if nobody can use it. When possible, the system should be compatible with existing code and approaches. New language features should borrow syntax and semantics from other languages users might be familiar with. APIs and tools might need to support complicated and detailed use-cases, but should also provide conveniences and short-cuts for the most common cases.
 
diff --git a/docs/user-guide/02-conventional-features.md b/docs/user-guide/02-conventional-features.md
index 0c8a44d10..a28b7f8cb 100644
--- a/docs/user-guide/02-conventional-features.md
+++ b/docs/user-guide/02-conventional-features.md
@@ -6,9 +6,9 @@ Conventional Language Features
 ==============================
 
 Many of the language concepts in Slang are similar to those in other real-time shading languages like HLSL and GLSL, and also to general-purpose programming languages in the "C family."
-This chapter covers those parts of the Slang language that are _conventional_ and thus unlikley to surprise users who are already familiar with other shading languages, or languages in the C family.
+This chapter covers those parts of the Slang language that are _conventional_ and thus unlikely to surprise users who are already familiar with other shading languages, or languages in the C family.
 
-Readers who are comfortable with HLSL variables, types, functions, statements, as well as concentions for shader parameters and entry points may prefer to skip this chapter.
+Readers who are comfortable with HLSL variables, types, functions, statements, as well as conventions for shader parameters and entry points may prefer to skip this chapter.
 Readers who are not familiar with HLSL, but who are comfortable with GLSL and/or C/C++, may want to carefully read the sections on types, expressions, shader parameters, and entry points while skimming the others.
 
 Types
@@ -39,7 +39,7 @@ The following integer types are provided:
 
 All targets support the 32-bit `int` and `uint` types, but support for the other types depends on the capabilities of each target platform.
 
-Integer literals can be both decimal and hexidecimal, and default to the `int` type.
+Integer literals can be both decimal and hexadecimal, and default to the `int` type.
 A literal can be explicitly made unsigned with a `u` suffix.
 
 The following floating-point type are provided:
@@ -66,7 +66,7 @@ Vector types can be written as `vector<T,N>` where `T` is a scalar type and `N`
 The type `vector<T,N>` is a vector of `N` _elements_ (also called _components_) each of type `T`.
 
 As a convenience, pre-defined vector types exist for each scalar type and valid element count, with a name using the formula `<<scalar-type>><<element-count>>`.
-For example, `float3` is a convient name for `vector<float,3>`.
+For example, `float3` is a convenient name for `vector<float,3>`.
 
 ### Matrix Types
 
@@ -74,7 +74,7 @@ Matrix types can be written as `matrix<T,R,C>` where `T` is a scalar type and bo
 The type `matrix<T,R,C>` is a matrix with _elements_ of type `T`, and comprising `R` rows and `C` columns.
 
 As a convenience, pre-defined matrix types exist for each scalar type and valid row/column count, with a name using the formula `<<scalar-type>><<row-count>>x<<column-count>>`.
-For example, a `float3x4` is a convient name for `matrix<float,3,4>`.
+For example, a `float3x4` is a convenient name for `matrix<float,3,4>`.
 
 > #### Note ####
 > Readers familiar with GLSL should be aware that a Slang `float3x4` represents a matrix with three rows and four columns, while a GLSL `mat3x4` represents a matrix with three *columns* and four *rows*.
@@ -209,13 +209,13 @@ Flat buffers are either _structured_ buffers or _byte-addressed_ buffers.
 
 Structured buffer types like `StructuredBuffer<T>` include an explicit element type `T` that will be loaded and stored from the buffer.
 Byte-addressed buffer types like `ByteAddressBuffer` do not specify any particular element type, and instead allow for values to be loaded or stored from any (suitably aligned) byte offset in the buffer.
-Both structured and byte-addressed bufers can use an _access_ to distinguish between read-only and read-write usage.
+Both structured and byte-addressed buffers can use an _access_ to distinguish between read-only and read-write usage.
 
 ##### Constant Buffers
 
 Constant buffers (sometimes also called "uniform buffers") are typically used to pass immutable parameter data from a host application to GPU code.
 The constant buffer type `ConstantBuffer<T>` includes an explicit element type.
-Unlike formatted or flat buffers, a constant buffer conceptualy contains only a *single* value of its element type, rather than one or more values.
+Unlike formatted or flat buffers, a constant buffer conceptually contains only a *single* value of its element type, rather than one or more values.
 
 Expressions
 -----------
@@ -233,7 +233,7 @@ Slang supports the following expression forms with nearly identical syntax to HL
 
 * Vector/matrix initialization: `int4(1, 2, 3, 4)`
 
-* Casts: `(int) x`, `double(0.0)`
+* Casts: `(int)x`, `double(0.0)`
 
 * Subscript (indexing): `a[i]`
 
@@ -290,7 +290,7 @@ Slang supports the following statement forms with nearly identical syntax to HLS
 
 > #### Note ####
 > Unlike C/C++, `case` and `default` statements must be directly nested under a `switch`, rather than being allowed under nested control flow (Duff's Device and similar idioms are not allowed).
-> In addition, while multiple `case`s can be grouped together, all other forms of "fallthrough" are unsupported.
+> In addition, while multiple `case`s can be grouped together, all other forms of "fall through" are unsupported.
 
 * `for` statements
 
@@ -356,8 +356,7 @@ Slang supports a C-style preprocessor with the following directives;
 * `#line`
 * `#pragma`, including `#pragma once`
 
-> #### Note ####
-> Variadic macros are not currently supported by the Slang preprocessor.
+Variadic macros are supported by the Slang preprocessor.
 
 Attributes
 ----------
@@ -417,7 +416,7 @@ Each logical thread of shader execution initiated by the GPU will be allocated f
 Global shader parameters may use any type, including both opaque and non-opaque types:
 
 ```hlsl
-ConstantBufer<MyData> c;
+ConstantBuffer<MyData> c;
 Texture2D t;
 float4 color;
 ```
@@ -542,7 +541,7 @@ Standard system-defined semantics are distinguished by the `SV_` prefix.
 A system-defined binding semantic on an input parameter indicates that the parameter should receive specific data from the GPU as defined by the pipeline and stage being used.
 For example, in a vertex shader the `SV_VertexID` binding semantic on an input yields the ID of the particular vertex being processed on the current thread.
 
-A system-defined binding semantic on an ouptput parameter or function result indicates that when a shader thread returns from the entry point the value stored in that output should be used by the GPU in a specific way defined by the pipeline and stage being used.
+A system-defined binding semantic on an output parameter or function result indicates that when a shader thread returns from the entry point the value stored in that output should be used by the GPU in a specific way defined by the pipeline and stage being used.
 For example, in a vertex shader the `SV_Position` binding semantic on an output indicates that it represents a clip-space position that should be communicated to the rasterizer.
 
 The set of allowed system-defined binding semantics for inputs and outputs depends on the pipeline and stage of an entry point.
diff --git a/docs/user-guide/03-convenience-features.md b/docs/user-guide/03-convenience-features.md
index 57286dfb1..011939ddb 100644
--- a/docs/user-guide/03-convenience-features.md
+++ b/docs/user-guide/03-convenience-features.md
@@ -106,7 +106,7 @@ void test()
 
 ## Properties
 
-Properties provide a convienient way to access values exposed by a type, where the logic behind accessing the value is defined in `getter` and `setter` function pairs. Slang's `property` feature is similar to C# and Swift. 
+Properties provide a convenient way to access values exposed by a type, where the logic behind accessing the value is defined in `getter` and `setter` function pairs. Slang's `property` feature is similar to C# and Swift. 
 ```csharp
 struct MyType
 {
@@ -296,7 +296,7 @@ This feature is similar to extensions in Swift and partial classes in C#.
 Modules
 -------
 
-While you can still organize code using preprocssor `#include`s, Slang also supports a _module_ system.
+While you can still organize code using preprocessor `#include`s, Slang also supports a _module_ system.
 
 ### Importing a Module