docs: Reduce typo count (#5671)

Co-authored-by: Ellie Hermaszewska <ellieh@nvidia.com>

5 files changed, 28 insertions, 28 deletions

diff --git a/docs/proposals/legacy/001-basic-interfaces.md b/docs/proposals/legacy/001-basic-interfaces.md
index 6083c8ae9..669537b42 100644
--- a/docs/proposals/legacy/001-basic-interfaces.md
+++ b/docs/proposals/legacy/001-basic-interfaces.md
@@ -232,7 +232,7 @@ These would be the first `interface`s officially exposed by the core module.
 While most of our existing code written in Slang uses an `I` prefix as the naming convention for `interface`s (e.g., `IThing`), we have never really discussed that choice in detail.
 Whatever we decide to expose for this stuff is likely to become the de facto convention for Slang code.
 
-The `I` prefix is precedented in COM and C#/.net/CLR, which are likely to be familiar to many devleopers using Slang.
+The `I` prefix is precedented in COM and C#/.net/CLR, which are likely to be familiar to many developers using Slang.
 Because of COM, it is also the convention used in the C++ API headers for Slang and GFX.
 
 The Rust/Swift languages do not distinguish between traits/protocols and other types.
diff --git a/docs/proposals/legacy/002-api-headers.md b/docs/proposals/legacy/002-api-headers.md
index 66b649228..5efbc1d16 100644
--- a/docs/proposals/legacy/002-api-headers.md
+++ b/docs/proposals/legacy/002-api-headers.md
@@ -29,7 +29,7 @@ We know that we cannot remove support for difficult cases, but it would be good
 Related Work
 ------------
 
-There are obviously far too many C/C++ APIs and approachs to design for C/C++ APIs for us to review them all.
+There are obviously far too many C/C++ APIs and approaches to design for C/C++ APIs for us to review them all.
 We will simply note a few key examples that can be relevant for comparison.
 
 The gold standard for C/C++ APIs is ultimately plain C. Plain C is easy for most systems programmers to understand and benefits from having a well-defined ABI on almost every interesting platform. FFI systems for other languages tend to work with plain C APIs. Clarity around ABI makes it easy to know what changes/additions to a plain C API will and will not break binary compatibility. The Cg compiler API and the Vulkan GPU API are good examples of C-based APIs in the same domains as Slang and GFX, respectively. These APIs reveal some of the challenges of using plain C for large and complicated APIs:
@@ -64,7 +64,7 @@ Across such APIs, we see a wide variety of strategies to dealing with extensibil
 
 * Vulkan uses "desc" structures (usually called "info" or "create info" structures), which contain a baseline set of state/fields, along with a linked list of dynamically-typed/-tagged extension structures. New functionality that only requires changes to "desc" structures can be added by defining a new tag and extension structure. New operations are added in a manner similar to OpenGL.
 
-* D3D12 also uses COM interfaces and "desc" structures (although now officialy called "descriptions" to not overload the use of "descriptor" in descriptor tables), much like D3D11, and sometimes uses the same approach to extensibility (e.g., there are currently `ID3D12Device`, `ID3D12Device`, ... `ID2D12Device9`). In addition, D3D12 has also added two variations on Vulkan-like models for creating pipeline state (`ID3D12Device2::CreatePipelineState` and `ID3D12Device5::CreateStateObject`), using a notion of more fine-grained "subojects" that are dynamically-typed/-tagged and each have their own "desc".
+* D3D12 also uses COM interfaces and "desc" structures (although now officially called "descriptions" to not overload the use of "descriptor" in descriptor tables), much like D3D11, and sometimes uses the same approach to extensibility (e.g., there are currently `ID3D12Device`, `ID3D12Device`, ... `ID2D12Device9`). In addition, D3D12 has also added two variations on Vulkan-like models for creating pipeline state (`ID3D12Device2::CreatePipelineState` and `ID3D12Device5::CreateStateObject`), using a notion of more fine-grained "subojects" that are dynamically-typed/-tagged and each have their own "desc".
 
 It is important to note that even with the nominal flexibility that COM provides around versioning, D3D12 has opted for a more fine-grained approach when dealing with something as complicated as GPU pipeline state.
 
@@ -91,7 +91,7 @@ At the end of this document there is a lengthy code block that sketches a possib
 Questions
 ---------
 
-### Will we generate all or some of the API header? If so, what will be the "ground truth" verison?
+### Will we generate all or some of the API header? If so, what will be the "ground truth" version?
 
 Note that Vulkan and SPIR-V benefit from having ground-truth computer-readable definitions, allowing both header files and tooling code to be generated.
 
@@ -278,7 +278,7 @@ namespace slang
         members initializers in `slang::SessionDesc`, but it *will* compile
         under C++14 and later.
 
-        If we want to deal with C++11 compatiblity in that case, we can, but
+        If we want to deal with C++11 compatibility in that case, we can, but
         it would slightly clutter up the way we declare these things. Realistically,
         we'd just split the two types:
 
@@ -325,7 +325,7 @@ namespace slang
 
         struct SessionDesc0 { ... the original ... };
         struct SessionDesc1 { ... the new one ... };
-        typedef SessionDesc SesssionDesc1;
+        typedef SessionDesc SessionDesc1;
 
     At the point where we introduce a second version, it is probably the right time
     to enable developers to lock in to any version they choose. In the code above
@@ -334,7 +334,7 @@ namespace slang
     at the point they compile.
 
     (If we wanted to get really "future-proof" we'd define every struct with the `0`
-    prefix right out of the gate, and always have the `typedef` in place. I'm not conviced
+    prefix right out of the gate, and always have the `typedef` in place. I'm not convinced
     that would ever pay off.)
     
     I expect most of this to be a non-issue if we are zealous about using fine-grained
@@ -368,7 +368,7 @@ namespace slang
             UUID const&         uuid,
             void**              outObject) = 0;
 
-        /* Instead, most users will direclty call the operations only through
+        /* Instead, most users will directly call the operations only through
         wrappers that provide conveniently type-safe behavior:
         */
         inline Result createCompileRequest(
@@ -574,7 +574,7 @@ extern "C"
     and also to provide versioning support.
 
     We could define the same set of overloads here, with the same names, for
-    use by clients who don't actually care about C compatiblity but just like
+    use by clients who don't actually care about C compatibility but just like
     a C-style API. That is probably worth doing.
 
     Otherwise, we realistically need to start defining some de-facto naming
@@ -612,7 +612,7 @@ extern "C"
 
     /* Finally, the C API level is where we should define the core factory entry
     point for creating and initializing the Slang global session (just like
-    in the current header). Here we jsut generalize it for creaitng "any" global
+    in the current header). Here we just generalize it for creaitng "any" global
     object, based on a UUID and a bunch of descs.
     */
     SLANG_API SlangResult slang_createObject(
@@ -645,7 +645,7 @@ generating as much of the API as possible anyway.
 
 /* Basic Types */
 
-    /* We just define the basic types direclty, without the indirection
+    /* We just define the basic types directly, without the indirection
     through the declarations in the `slang::` namespace.
     */
 
@@ -846,7 +846,7 @@ use of exceptions instead of `Result`s:
         SLANG_SMART_PTR(ICompileRequest) createCompileRequest(
             CompileRequestDesc const& desc)
         {
-            SLANG_SMART_PTR(ICompileReqest) compileRequest;
+            SLANG_SMART_PTR(ICompileRequest) compileRequest;
             SLANG_THROW_IF_FAIL(_createCompileRequest(
                 &desc, 1, SLANG_UUID_OF(IComileRequest), comileRequest.writeRef()));
             return compileRequest;
@@ -857,7 +857,7 @@ use of exceptions instead of `Result`s:
 #endif
     }
 
-Both for the sake of C API and especialy for gfx (both C and C++), we should consider
+Both for the sake of C API and especially for gfx (both C and C++), we should consider
 defining some coarse-grained aggregate desc types as utilities:
 
     struct SimpleRasterizationPipelineStateDesc
@@ -886,7 +886,7 @@ defining some coarse-grained aggregate desc types as utilities:
         // List<T> members for attachments, etc. rather than just pointer-and-count:
 
         private: List<AttachmentDesc> colorAttachments;
-        public: AttachmentDesc& addColorAttachement();
+        public: AttachmentDesc& addColorAttachment();
 
         // There should also be convenience constructors common cases
         // (especially relevant for things like textures).
@@ -924,7 +924,7 @@ defining some coarse-grained aggregate desc types as utilities:
     };
 
 While the implementation of this monolithic desc types would not necessarily be pretty,
-it would enable users who want the benefits of the "one big struct" appraoch to get
+it would enable users who want the benefits of the "one big struct" approach to get
 what they seem to want.
 
 The next step down this road is to take these aggregate desc types and turn them into
diff --git a/docs/proposals/legacy/003-error-handling.md b/docs/proposals/legacy/003-error-handling.md
index 23c7bdc40..e8fb44402 100644
--- a/docs/proposals/legacy/003-error-handling.md
+++ b/docs/proposals/legacy/003-error-handling.md
@@ -43,10 +43,10 @@ Related Work
 In the absence of language support, developers typically signal and propagate errors using *error codes*. The COM `HRESULT` type is a notable example of a well-defined system for using error codes in C/C++ and other languages.
 Error codes have the benefit of being easy to implement, and relatively light-weight.
 The main drawback of error codes is that developers often forget to check and/or propagate them, and when they do remember to do so it adds a lot of boilerplate.
-Additonally, reserving the return value of every function for returning an error code makes code more complex because the *actual* return value must be passed via a function parameter.
+Additionally, reserving the return value of every function for returning an error code makes code more complex because the *actual* return value must be passed via a function parameter.
 
 C++ uses *exceptions* for errors in various categories, including unpredictable but recoverable failures.
-Propagation of errors up the call stack is entirely automatic, with unwinding of call frames and destruction of their local state occuring as part of the search for a handler.
+Propagation of errors up the call stack is entirely automatic, with unwinding of call frames and destruction of their local state occurring as part of the search for a handler.
 Neither functions that may throw nor call sites to such functions are syntactically marked.
 Exceptions in C++ have often been implemented in ways that add overhead and require complicated support in platform ABIs and intermediate languages to support.
 
@@ -66,7 +66,7 @@ Functions that return `X` and those that return `Result<X, ...>` are not directl
 Swift provides more syntactic support for errors than Rust, although the underlying mechanism is similar.
 A Swift function may have `throws` added between the parameter list and return type to indicate that a function may yield an error.
 All errors in Swift must implement the `Error` protocol, and all functions that can `throw` may produce any `Error` (although there are proposals to extend Swift with "typed `throws`").
-Any call site to a `throws` function must have a prefix `try` (e.g., `try f(a, b)`), which works simiarly to Rust's `?`; any error produced by the called function is propagated, and the ordinary result is returned.
+Any call site to a `throws` function must have a prefix `try` (e.g., `try f(a, b)`), which works similarly to Rust's `?`; any error produced by the called function is propagated, and the ordinary result is returned.
 Swift provides an explicit `do { ... } catch ...` construct that allows handlers to be established.
 It also provides for conversion between exceptions and an explicit `Result<T,E>` type, akin to Rust's.
 Higher-order functions may be declared as `rethrows` to indicate that whether or not they throw depends on whether or not any of their function-type parameters is actually a `throws` function at a call site.
@@ -203,7 +203,7 @@ let y : int = 1 + _tmp;
 
 ### Desugar `throw` Expressions
 
-For every `throw` site in a function body, there will either be no in-scope `catch` clause that matches the type thrown, or there will be eactly one most-deeply-nested `catch` that statically matches.
+For every `throw` site in a function body, there will either be no in-scope `catch` clause that matches the type thrown, or there will be exactly one most-deeply-nested `catch` that statically matches.
 Front-end semantic checking should be able to associate each `throw` with the appropriate `catch` if any.
 
 For `throw` sites with no matching `catch`, the operation simply translates to a `return` of the thrown error (because of the way we transformed the function signature).
diff --git a/docs/proposals/legacy/005-components.md b/docs/proposals/legacy/005-components.md
index b257140a7..ff53d0f77 100644
--- a/docs/proposals/legacy/005-components.md
+++ b/docs/proposals/legacy/005-components.md
@@ -239,7 +239,7 @@ class X
 ```
 
 In the above, an instance of `X` can always find the `Y` it depends on easily and (relatively) efficiently.
-There is no particularly high overhead to having `X` diretly store an indirect reference to `Y` (at least not for coarse-grained units), and it is trivial for multiple units like `X` to all share the same *instance* of `Y` (potentially even including mutable state, for applications that like that sort of thing).
+There is no particularly high overhead to having `X` directly store an indirect reference to `Y` (at least not for coarse-grained units), and it is trivial for multiple units like `X` to all share the same *instance* of `Y` (potentially even including mutable state, for applications that like that sort of thing).
 
 In general most CPU languages (and especially OOP ones) can express the concepts of "is-a" and "has-a" but they often don't distinguish between when "has-as" means "refers-to-and-depends-on-a" vs. when it means "aggregates-and-owns-a".
 This is important when looking at a GPU language like Slang, where "aggergates-and-owns-a" is easy (we have `struct` types), but "refers-to-and-depends-on-a" is harder (not all of our targets can really support pointers).
@@ -279,7 +279,7 @@ interface IMaterialSystem
     void doMaterialStuff();
 }
 
-__component_type DefualtMaterialSystem : IMaterialSystem
+__component_type DefaultMaterialSystem : IMaterialSystem
 {
     __require lighting : ILightingSystem;
 
@@ -365,7 +365,7 @@ At the point where an `__aggregate SomeType` member is declared, the front-end s
 For example, because `DefaultIntegratorSystem` declares `__require IMaterialSystem`, the compiler searches in the current context for a value that can provide that interface.
 It finds a single suitable value: the value implicitly defined by `__aggregate DefaultMaterialSystem`, and thus "wires up" the input dependency of the `DefaultIntegratorSystem`.
 
-It is posible for a `__require` in an `__aggregate`d member to be satisfied via another `__require` of its outer type:
+It is possible for a `__require` in an `__aggregate`d member to be satisfied via another `__require` of its outer type:
 
 ```
 __component_type MyUnit
@@ -384,7 +384,7 @@ While the above examples do not show it, component types should be allowed to co
 Detailed Explanation
 --------------------
 
-Component types need to be restricted in where and how they can be used, to avoid creating situations that would give them all the flexiblity of arbitrary `class`es.
+Component types need to be restricted in where and how they can be used, to avoid creating situations that would give them all the flexibility of arbitrary `class`es.
 The only places where a component type may be used are:
 
 * `__require` and `__aggregate` declarations
@@ -434,7 +434,7 @@ Note that when the generated code invokes an operation through one of the `__agg
 
 Effectively, the compiler generates all of the boilerplate parameter-passing that the programmer would have otherwise had to write by hand.
 
-It might or might not be obvious that the notion of "component type" being described here has a clear correspondance to the `IComponentType` interface provided by the Slang runtime/compilation API.
+It might or might not be obvious that the notion of "component type" being described here has a clear correspondence to the `IComponentType` interface provided by the Slang runtime/compilation API.
 It should be possible for us to provide reflection services that allow a programmer to look up a component type by name and get an `IComponentType`.
 The existing APIs for composing, specializing, and linking `IComponentType`s should Just Work for explicit `__component_type`s.
 Large aggregates akin to `MyProgram` above can be defined entirely via the C++ `IComponentType` API at program runtime.
@@ -456,7 +456,7 @@ That last point is important, since a component type allows users to define a co
 
 ### Can the `__component_type` construct just be subsumed by either `struct` or `class`?
 
-Maybe. The key challenge is that component types need to provide the "look and feel" of by-refernece re-use rather than by-value copying. A `__require T` should effectively act like a `T*` and not a bare `T` value, so I am reluctant to say that should map to `struct`.
+Maybe. The key challenge is that component types need to provide the "look and feel" of by-reference re-use rather than by-value copying. A `__require T` should effectively act like a `T*` and not a bare `T` value, so I am reluctant to say that should map to `struct`.
 
 ### But what about `[mutating]` operations and writing to fields of component types, then?
 
@@ -484,7 +484,7 @@ __component_type C { __require A; ... }
 __component_type D { __require B; __require C; ... }
 ```
 
-The Spark shading language research project used multiple mixin class inheritance to compose units of shader code akin to what are being proposed here as coponent types (hmm... I guess that should go into related work...).
+The Spark shading language research project used multiple mixin class inheritance to compose units of shader code akin to what are being proposed here as component types (hmm... I guess that should go into related work...).
 
 In general, using inheritance to model something that isn't an "is-a" relationship is poor modeling.
 Inheritance as a modelling tool cannot capture some patterns that are possible with `__aggregate` (notably, with mixin inheritance you can't get multiple "copies" of a component).
diff --git a/docs/proposals/legacy/006-artifact-container-format.md b/docs/proposals/legacy/006-artifact-container-format.md
index 81910151b..04daf3bd4 100644
--- a/docs/proposals/legacy/006-artifact-container-format.md
+++ b/docs/proposals/legacy/006-artifact-container-format.md
@@ -491,7 +491,7 @@ The grouping - how does it actually work? It might require specifying what group
 
 An advantage to this approach is that policy of how naming works as a user space problem. It is also powerful in that it allows control on compilation that has some independence from the name.
 
-We could have some options that are named, but do not appear as part of the name/path within the container. The purpose of this is to allow customization of a compilation, without that customization necessarily appearing withing the application code. The container could store group of named options that is used, such that it is possible to recreate the compilation or perhaps to detect there is a difference. 
+We could have some options that are named, but do not appear as part of the name/path within the container. The purpose of this is to allow customization of a compilation, without that customization necessarily appearing within the application code. The container could store group of named options that is used, such that it is possible to recreate the compilation or perhaps to detect there is a difference.
 
 ### JSON options
 
@@ -776,7 +776,7 @@ Discussion: Container
 
 A typical container will contain kernels - in effect blobs. The blobs themselves, or the blob names are not going to be sufficient to express the amount of information that is necessary to meet the goals laid out at the start of this document. Some extra information may be user supplied. Some extra information might be user based to know how to classify different kernels. Therefore it is necessary to have some system to handle this metadata. 
 
-As previously discussed the underlying container format is a file system. Some limited information could be infered from the filename. For example a .spv extension file is probably SPIR-V blob. For more rich meta data describing a kernel something more is needed. Two possible approaches could be to have a 'manifest' that described the contents of the container. Another approach would to have a file associated with the kernel that describes it's contents.
+As previously discussed the underlying container format is a file system. Some limited information could be inferred from the filename. For example a .spv extension file is probably SPIR-V blob. For more rich meta data describing a kernel something more is needed. Two possible approaches could be to have a 'manifest' that described the contents of the container. Another approach would to have a file associated with the kernel that describes it's contents.
 
 Single Manifest Pros