Spelling docs

docs/ABI/Mangling.rst

@@ -305,7 +305,7 @@ witness functions for a type.
   AUTODIFF-FUNCTION-KIND ::= 'd'        // differential
   AUTODIFF-FUNCTION-KIND ::= 'p'        // pullback
 
-``<AUTODIFF-FUNCTION-KIND>`` differentiates the kinds of functions assocaited
+``<AUTODIFF-FUNCTION-KIND>`` differentiates the kinds of functions associated
 with a differentiable function used for differentiable programming.
 
 ::
@@ -596,7 +596,7 @@ Types
   FUNCTION-KIND ::= 'zB' C-TYPE              // objc block type with non-canonical C type
   FUNCTION-KIND ::= 'L'                      // objc block function type with canonical C type (escaping) (DWARF only; otherwise use 'B' or 'zB' C-TYPE)
   FUNCTION-KIND ::= 'C'                      // C function pointer / C++ method type
-  FUNCTION-KIND ::= 'zC' C-TYPE              // C function pointer / C++ method type with with non-canonical C type
+  FUNCTION-KIND ::= 'zC' C-TYPE              // C function pointer / C++ method type with non-canonical C type
   FUNCTION-KIND ::= 'A'                      // @auto_closure function type (escaping)
   FUNCTION-KIND ::= 'E'                      // function type (noescape)
 

docs/CppInteroperability/CppInteroperabilityManifesto.md

@@ -1625,7 +1625,7 @@ is ergonomics.
 
 While Swift structs are a bad match for non-movable C++ classes, Swift classes
 match semantics better. For example, instances of Swift classes, once allocated,
-stay at the same address until `deinit`. Instances of Swift clasess are always
+stay at the same address until `deinit`. Instances of Swift classes are always
 worked with indirectly, eliminating the need to move them around in memory.
 
 Although user-defined Swift classes have a certain memory layout determined by
@@ -2524,7 +2524,7 @@ there the Swift compiler infers the attribute for all users.
 This analysis relies on over-approximating the dynamic callgraph with the static
 callgraph. The static callgraph is feasible to compute in most cases, since
 Swift has very limited ways to abstract over an unspecialized generic function.
-Speicifically, Swift does not have generic closures. Swift does allow protocols
+Specifically, Swift does not have generic closures. Swift does allow protocols
 to have requirements for generic functions though.
 
 ### Function templates: importing as real generic functions
@@ -2963,7 +2963,7 @@ This brief sketch obviously leaves many questions unanswered on the detailed
 semantics that a `throws!` feature would have, for example whether user-written
 Swift code should be allowed to use `throws!` -- see also [this forum
 discussion](https://forums.swift.org/t/handling-c-exceptions/34823). Before we
-take any steps towards implementing C++ exception proagation, we will submit a
+take any steps towards implementing C++ exception propagation, we will submit a
 formal Swift Evolution proposal for the `throws!` feature.
 
 The other question to answer is how we would map the C++ exception to a

docs/CppInteroperability/GettingStartedWithC++Interop.md

@@ -18,7 +18,7 @@ This document is designed to get you started with bidirectional API-level intero
 ```
 //In module.modulemap
 module Cxx {
-    //note that your header should be the file that containts your method implementations
+    //note that your header should be the file that contains your method implementations
     header "Cxx.hpp"
     requires cplusplus
 }

docs/CppInteroperability/InteropOddities.md

@@ -12,7 +12,7 @@ are bridged as value types. ⚠️ This will change as soon as Swift has a way t
 
 Currently, lifetimes are extended to the end of the lexical scope if any unsafe pointers are used in that scope. TODO: 
 this should be updated to extend lifetimes whenever a C++ type is used in that scope. Currently, if there is no 
-unsafe pointer used in teh scope, then normal Swift lifetime rules apply.   
+unsafe pointer used in the scope, then normal Swift lifetime rules apply.   
 
 **Borrowing Self**
 

docs/DebuggingTheCompiler.md

@@ -599,7 +599,7 @@ find MyProject/Sources -name '*.swift' -type f > input-files.txt
 # In some cases, projects may use multiple files with the same
 # name but in different directories (for different schemes),
 # which can be a problem. Having a file list makes working around
-# this convenient as you can manually manually edit out the files
+# this convenient as you can manually edit out the files
 # that are not of interest at this stage.
 
 mkdir Output

docs/DevelopmentTips.md

@@ -42,7 +42,7 @@ Given the size of artifacts generated, you might also want to bump the cache siz
 
 You can run some compiles to see if it is actually doing something by running `sccache --show-stats`. Depending on the exact compilation task you're running, you might see very different cache hit rates. For example, `sccache` is particularly effective if you're rebuilding LLVM, which doesn't change so frequently from the Swift compiler's perspective. On the other hand, if you're changing the compiler's AST, the cache hit rate is likely to be much lower.
 
-One known issue with `sccache` is that you might occassionally get an "error: Connection to server timed out", even though you didn't stop the server. Simply re-running the build command usually works.
+One known issue with `sccache` is that you might occasionally get an "error: Connection to server timed out", even though you didn't stop the server. Simply re-running the build command usually works.
 
 ## Memory usage
 

docs/Lexicon.md

@@ -239,7 +239,7 @@ Describes contributions which fix code that is not executed
 Provides context for interpreting a type that may have generic parameters
 in it. Generic parameter types are normally just represented as "first
 generic parameter in the outermost context" (or similar), so it's up to the
-generic environment to note that that type must be a Collection. (Another
+generic environment to note that type must be a Collection. (Another
 way of looking at it is that the generic environment connects
 [interface types](#interface-type) with
 [contextual types](#contextual-type)).

docs/OptimizationTips.rst

@@ -183,7 +183,7 @@ sources all together at once. This allows the optimizer to have module
 wide visibility when compiling individual declarations. Since an
 internal declaration is not visible outside of the current module, the
 optimizer can then infer `final` by automatically discovering all
-potentially overridding declarations.
+potentially overriding declarations.
 
 NOTE: Since in Swift the default access control level is ``internal``
 anyways, by enabling Whole Module Optimization, one can gain

docs/OwnershipManifesto.md

@@ -393,7 +393,7 @@ called function where it isn't obviously using its `inout`
 argument.  Perhaps we should track accesses to `inout` arguments
 at a finer-grained level, within the callee, instead of attempting
 to enforce the Law of Exclusivity in the caller.  The problem
-is that that idea is simply too dynamic to be efficiently
+is that idea is simply too dynamic to be efficiently
 implemented.
 
 A caller-side rule for `inout` has one key advantage: the
@@ -1163,7 +1163,7 @@ here because, as mentioned above, the entire co-routine
 must logically execute within the scope of an access to the
 base value.  If, as is common for generators, the generator
 function actually returns some sort of generator object,
-the compiler must ensure that that object does not escape
+the compiler must ensure that object does not escape
 that enclosing access.  This is a significant source of
 complexity.
 

docs/ReferenceGuides/UnderscoredAttributes.md

@@ -46,7 +46,7 @@ available for emission into clients with deployment targets lower than the
 ABI availability of the function. When the client's deployment target is
 before the function's ABI availability, the compiler replaces calls to that
 function with a call to a thunk that checks at runtime whether the original
-library function is available. If the the original is available then it is
+library function is available. If the original is available then it is
 called. Otherwise, the fallback copy of the function that was emitted into the
 client is called instead.
 
@@ -640,7 +640,7 @@ Here are the necessary changes:
    This ensures when an app is built for deployment targets prior to the symbols' move,
    the app will look for these symbols in ToasterKit instead of ToasterKitCore.
 
-More generally, mutliple availabilities can be specified, like so:
+More generally, multiple availabilities can be specified, like so:
 
 ```swift
 @available(toasterOS 42, bowlOS 54, mugOS 54, *)

docs/RequirementMachine/RequirementMachine.tex

@@ -218,7 +218,7 @@ \chapter{Language Overview}\label{languageoverview}
 \end{Verbatim}
 A particularly powerful kind of generic requirement---and perhaps the entire reason the requirement machine exists---is the same-type requirement.
 
-Supppose you're working with $\genericparam{S}$, a generic parameter ranging over $\proto{Sequence}$. Writing $\genericparam{S}.\namesym{Iterator}.\namesym{Element}$ everywhere will get awkward fast. As I mentioned, the real version of $\proto{Sequence}$ in the standard library is slightly more complex. Indeed, it defines an $\namesym{Element}$ associated type in the protocol itself, so that the user can write $\genericparam{S}.\namesym{Element}$. Simply adding the associated type definition is not enough, because now $\genericparam{S}.\namesym{Element}$ and $\genericparam{S}.\namesym{Iterator}.\namesym{Element}$ are \emph{different} type parameters and cannot be used interchangeably.
+Suppose you're working with $\genericparam{S}$, a generic parameter ranging over $\proto{Sequence}$. Writing $\genericparam{S}.\namesym{Iterator}.\namesym{Element}$ everywhere will get awkward fast. As I mentioned, the real version of $\proto{Sequence}$ in the standard library is slightly more complex. Indeed, it defines an $\namesym{Element}$ associated type in the protocol itself, so that the user can write $\genericparam{S}.\namesym{Element}$. Simply adding the associated type definition is not enough, because now $\genericparam{S}.\namesym{Element}$ and $\genericparam{S}.\namesym{Iterator}.\namesym{Element}$ are \emph{different} type parameters and cannot be used interchangeably.
 
 \index{same-type requirement}
 To express this restriction that concrete types conforming to $\proto{Sequence}$ must provide an iterator type compatible with the element type, a \texttt{where} clause in the protocol can state a same-type requirement:
@@ -261,7 +261,7 @@ \chapter{Language Overview}\label{languageoverview}
 \[\genericparam{T}.\namesym{Element} == \namesym{Int}.\]
 
 \index{power set}
-One more small language feature is worth mentioning. You might want to define a function that constructs the the set of all subsets of a set, i.e., the power set. The $\namesym{Set}\langle\bullet\rangle$ type constructor requires that its argument conforms to $\proto{Hashable}$:
+One more small language feature is worth mentioning. You might want to define a function that constructs the set of all subsets of a set, i.e., the power set. The $\namesym{Set}\langle\bullet\rangle$ type constructor requires that its argument conforms to $\proto{Hashable}$:
 \begin{Verbatim}
 struct Set<Element : Hashable> {...}
 \end{Verbatim}
@@ -1390,7 +1390,7 @@ \chapter{Rewrite Systems}\label{rewritesystemintro}
 \begin{definition}[Reduction relation]\label{transinvdef} If $A^*$ is equipped with a reduction order $<$, then a relation $\rightarrow$ is a \emph{reduction relation} with respect to $<$ if $x\rightarrow y$ implies that $y<x$. Another equivalent definition is that a reduction relation $\rightarrow$ is a \emph{sub-relation} of $>$, the inverse relation of $<$. 
 \end{definition}
 \index{rewrite system}
-As you saw in the previous example, a reduction relation for a finitely-presented monoid can be constructed by orienting the equations from the presentation with respect to some reduction order, a process which converts the equations into rewrite rules. Such a set of rewrite rules is called a \emph{rewrite system}. There is a simple algorithm for for reducing a term into an irreducible form:
+As you saw in the previous example, a reduction relation for a finitely-presented monoid can be constructed by orienting the equations from the presentation with respect to some reduction order, a process which converts the equations into rewrite rules. Such a set of rewrite rules is called a \emph{rewrite system}. There is a simple algorithm for reducing a term into an irreducible form:
 \begin{algorithm}[Reducing a term]\label{reducingaterm} Let $t$ be a term in some rewrite system $R$.
 \begin{enumerate}
 \item Initialize the boolean flag to false.
@@ -2208,7 +2208,7 @@ \chapter{Associated Types}\label{associatedtypes}
 u&\leftrightarrow a\\
 v&\leftrightarrow b
 \end{align*}
-This means that adding a new \emph{generator} to $M$ made the presentation convergent. What does this generator represent in the world of Swift? Well, $u\in M'$ is $a\in M$, which is $\protosym{View}$ in Swift; and $v\in M'$ is $b\in M$, which is $\namesym{Body}$. Therefore $t\in M'$ is $ab\in M$, which is $\protosym{View}.\namesym{Body}$. You may guess that $t$ could be a new kind of symbol, perhaps representing a ``bound'' associated type inside a specific protcol.
+This means that adding a new \emph{generator} to $M$ made the presentation convergent. What does this generator represent in the world of Swift? Well, $u\in M'$ is $a\in M$, which is $\protosym{View}$ in Swift; and $v\in M'$ is $b\in M$, which is $\namesym{Body}$. Therefore $t\in M'$ is $ab\in M$, which is $\protosym{View}.\namesym{Body}$. You may guess that $t$ could be a new kind of symbol, perhaps representing a ``bound'' associated type inside a specific protocol.
 
 \index{associated type symbol}
  The crux of the issue is that name symbols like $\namesym{Body}$ don't carry any information, and little can be said about them unless they're prefixed with some other term that is known to conform to a protocol. Thus, you cannot simply add a rewrite rule to say that $\namesym{Body}$ conforms to $\protosym{View}$:
@@ -2369,7 +2369,7 @@ \chapter{Associated Types}\label{associatedtypes}
 \end{proof}
 
 \iffalse
-This solves the quandry presented at the beginning of this chapter, where the earlier formulation of the rewrite system that lacked associated type symbols had no apparent way of implementing the \texttt{getCanonicalTypeInContext()} generic signature query.
+This solves the quandary presented at the beginning of this chapter, where the earlier formulation of the rewrite system that lacked associated type symbols had no apparent way of implementing the \texttt{getCanonicalTypeInContext()} generic signature query.
 
 Now that a term containing name symbols reduces to a canonical term with associated type symbols, it appears that mapping terms back to fully resolved type parameters is now a possibility. Unfortunately, the reality is a little bit more complicated. The inherited associated type construction I will introduce in the next section once again breaks the correspondence between terms and canonical types; this will be repaired in Section \ref{implqueries}.
 \fi
@@ -3674,7 +3674,7 @@ \section{Generic Signature Queries}\label{implqueries}
 \item[\texttt{getRequiredProtocols()}] The list of protocol requirements satisfied by a type parameter $T$ is recorded in the form of protocol symbols in the property map. This list is transformed into a minimal canonical list of protocols using Definition~\ref{minimalproto}.
 \index{layout constraints}
 \index{join of layout constraints}
-\item[\texttt{getLayoutContraint()}] A type parameter $T$ might be subject to multiple layout constraints, in which case the property map entry will store a list of layout constraints $L_1,\ldots,L_n$. This query needs to compute their join, which is the largest layout constraint that simultaneously satisfies all of them:
+\item[\texttt{getLayoutConstraint()}] A type parameter $T$ might be subject to multiple layout constraints, in which case the property map entry will store a list of layout constraints $L_1,\ldots,L_n$. This query needs to compute their join, which is the largest layout constraint that simultaneously satisfies all of them:
 \[L_1\wedge\cdots\wedge L_n.\]
 Some layout constraints are disjoint on concrete types, meaning their join is the uninhabited ``bottom'' layout constraint, which precedes all other layout constraints in the partial order. In this case, the original generic signature is said to have conflicting requirements. While such a signature does not violate the requirement machine's invariants, it cannot be satisfied by any valid set of concrete substitutions. Detecting and diagnosing conflicting requirements is discussed later.