[docs] Fix typos

docs/CppInteroperability/UserGuide-CallingSwiftFromC++.md

@@ -12,7 +12,7 @@ design for the Swift to C++ interoperability layer.
 **NOTE:** This document does not go over the following Swift language features yet:
 
 * Closures
-* overriden methods/properties in classes
+* overridden methods/properties in classes
 * Existential types (any P)
 * Nested types
 * Operators
@@ -72,7 +72,7 @@ Swift functions that are callable from C++ are available in their corresponding
 
 Fundamental primitive types have a C++ fundamental type that represents them in C++:
 
-|Swift Type    |C++ Type    |C Type (if different)    |    |target specifc    |
+|Swift Type    |C++ Type    |C Type (if different)    |    |target specific    |
 |---    |---    |---    |---    |---    |
 |Void (or no return)    |void    |    |    |    |
 |Int    |swift::Int    |ptrdiff_t    |long or long long (windows)    |YES    |
@@ -295,12 +295,12 @@ As an example, this structure renames its second `init` overload in C++ to expos
 
 ```swift
 // Swift module 'Weather'
-struct Celcius {
-  var temperatureInCelcius: Double
+struct Celsius {
+  var temperatureInCelsius: Double
 
   // FEEDBACK: could provide a constructor here?
   // NOTE: concern about encouraging people not to use labels
-  init(_ t: Double) { self.temperatureInCelcius = t }
+  init(_ t: Double) { self.temperatureInCelsius = t }
 
   // FEEDBACK: could the compiler construct the 'initFromFahrenheit' c++ name?
   @expose(c++, initFromFahrenheit)
@@ -315,8 +315,8 @@ Both initializers can then be used from C++:
 using namespace Weather;
 
 void makeSunnyDay() {
-  auto morningTemperature = Celcius::init(25);
-  auto noonTemperature    = Celcius::initFromFahrenheit(90);
+  auto morningTemperature = Celsius::init(25);
+  auto noonTemperature    = Celsius::initFromFahrenheit(90);
 }
 ```
 
@@ -558,7 +558,7 @@ public:
 
   using UpcType = swift::Tuple<swift::Int, swift::Int, swift::Int, swift::Int>;
 
-  // Extracts the associated valus from Barcode.upc enum case
+  // Extracts the associated values from Barcode.upc enum case
   UpcType getUpc() const;
 
   bool isQrCode() const;
@@ -698,7 +698,7 @@ public final class Bicycle: Vehicle {
 }
 ```
 
-Get a corresponding C++ class hierachy in C++:
+Get a corresponding C++ class hierarchy in C++:
 
 ```c++
 class Vehicle { ... };

docs/EmbeddedSwift/UserManual.md

@@ -252,11 +252,11 @@ For (2), external dependencies are also triggered by specific code needing them,
   - dependency: `void *__stack_chk_guard;`
   - dependency: `void __stack_chk_fail(void);`
   - stack protectors can be disabled with `-disable-stack-protector` swiftc flag
-- **atomics instrinsics**
+- **atomics intrinsics**
   - on CPU architectures that don't have direct load-acquire/store-release support in the ISA, LLVM calls helper functions for atomic operations
   - needed by refcounting in the Embedded Swift runtime (so any class usage will trigger this dependency)
   - also needed when using atomics from the Synchronization module
-- **multiplication/division/modulo instrinsics**
+- **multiplication/division/modulo intrinsics**
   - on CPU architectures that don't have direct support for the math operations in the ISA
   - dependency (on Mach-O): `__divti3`
   - dependency (on Mach-O): `__modti3`

docs/Generics/chapters/basic-operation.tex

@@ -136,7 +136,7 @@ This equivalence almost always holds true, except for these four situations wher
 \item If a conformance requirement is made redundant by a same-type requirement that fixes a type parameter to a concrete type (such as $\SameReq{T}{S}$ and $\ConfReq{T}{P}$ where \texttt{S} is a concrete type and $\ConfReq{S}{P}$ is a concrete conformance), the rewrite system cannot be reused for technical reasons; we will talk about this in \ChapRef{concrete conformances}.
 \end{enumerate}
 
-The first three only occur with invalid code, and are accompanied by diagnostics. The fourth is not an error, just a rare edge case where our optimization cannot be performed. All conditions are checked for during minimization, and recorded in the form of a flags field. We cannot install the minimization machine if any of these flags are set; doing so would associate a generic signature with a minimization machine that contains rewrite rules not explained by the generic signature itself. This would confuse subsequent generic signature queries. In the event that the above does not cover some other unforseen scenario where equivalence fails to hold, the \IndexFlag{disable-requirement-machine-reuse}\texttt{-disable-requirement-machine-reuse} frontend flag forces minimization machines to be discarded immediately after use, instead of being installed.
+The first three only occur with invalid code, and are accompanied by diagnostics. The fourth is not an error, just a rare edge case where our optimization cannot be performed. All conditions are checked for during minimization, and recorded in the form of a flags field. We cannot install the minimization machine if any of these flags are set; doing so would associate a generic signature with a minimization machine that contains rewrite rules not explained by the generic signature itself. This would confuse subsequent generic signature queries. In the event that the above does not cover some other unforeseen scenario where equivalence fails to hold, the \IndexFlag{disable-requirement-machine-reuse}\texttt{-disable-requirement-machine-reuse} frontend flag forces minimization machines to be discarded immediately after use, instead of being installed.
 
 \begin{example}
 The compiler builds several requirement machines while type checking the code below:

docs/Generics/chapters/completion.tex

@@ -742,7 +742,7 @@ We record a rewrite loop defining rule (*8) via rule (4), (6) and (7):
 \arrow[u, Rightarrow, "\ttgp{0}{0}.(\assocsym{P}{A}.\assocsym{Q}{B}\Rightarrow\assocsym{P}{A}.\texttt{B})"']&&
 \end{tikzcd}
 \]
-Note that this was an overlap of the first kind, so rule (7) is now marked \index{left-simplified rule}\textbf{left-simplified}. Thus, rule (*8) completely supercedes rule (7). Rule (*8) survives minimization and maps to the requirement $\ConfReq{\ttgp{0}{0}.[P]A.[Q]B}{R}$, which appears in the generic signature that we output for this protocol extension:
+Note that this was an overlap of the first kind, so rule (7) is now marked \index{left-simplified rule}\textbf{left-simplified}. Thus, rule (*8) completely supersedes rule (7). Rule (*8) survives minimization and maps to the requirement $\ConfReq{\ttgp{0}{0}.[P]A.[Q]B}{R}$, which appears in the generic signature that we output for this protocol extension:
 \begin{quote}
 \begin{verbatim}
 <τ_0_0 where τ_0_0: P, τ_0_0.[P]A.[Q]B: R>
@@ -1075,7 +1075,7 @@ Let $\Sigma_{\ConfReq{X}{S}}$ be the \index{protocol substitution map}protocol s
 \end{gather*}
 We see that applying $\Sigma_{\ConfReq{X}{S}}$ to \texttt{\ttgp{0}{0}.[S]A} and \texttt{\ttgp{0}{0}.[S]C.[S]B} also outputs identical types: $\AssocType{[S]A}\otimes\ConfReq{X}{S}=\AssocType{[S]B}\otimes\ConfReq{Y}{S}=\texttt{Int}$. Is this the case for \emph{every} conformance to \texttt{S}? That is, is it true that $G_\texttt{S}\vDash\SameReq{\texttt{\ttgp{0}{0}.A}}{\texttt{\ttgp{0}{0}.C.B}}$?
 
-We will see the answer is ``yes,'' proving that our function \texttt{f()} type checks. For a visual perspective, we turn to the \index{type parameter graph}type parameter graph\footnote{In our previous formulation, the type parameter graph has a distinguished root node, with every generic parameter as a child of this root. Now, our generic signature only has one generic parameter, so a root node would be superflous; we omit it in what follows.} for $G_\texttt{S}$. \FigRef{protocol s fig} constructs this graph in three steps. Between each step, we have a \index{graph homomorphism}graph homomorphism---in fact, a \index{covering map}covering map, in the sense of \SecRef{protocol component}---transforming one graph into the other:
+We will see the answer is ``yes,'' proving that our function \texttt{f()} type checks. For a visual perspective, we turn to the \index{type parameter graph}type parameter graph\footnote{In our previous formulation, the type parameter graph has a distinguished root node, with every generic parameter as a child of this root. Now, our generic signature only has one generic parameter, so a root node would be superfluous; we omit it in what follows.} for $G_\texttt{S}$. \FigRef{protocol s fig} constructs this graph in three steps. Between each step, we have a \index{graph homomorphism}graph homomorphism---in fact, a \index{covering map}covering map, in the sense of \SecRef{protocol component}---transforming one graph into the other:
 \begin{enumerate}
 \item The first step shows the graph as it would be without the protocol stating any same-type requirements; we get an infinite tree where each interior node is the parent of one other interior node, and two leaf nodes.
 
@@ -1681,7 +1681,7 @@ We saw that completion still fails; we get the following \index{infinite monoid
 \[M_2^{\prime} := \Pres{a,b,n,q}{nn\sim n,\,na\sim b,\,bn\sim b,\,ba\sim bb,\,qb^iq\sim qb^i,\, qb^ia\sim qb^{i+1}}\]
 However, we then add $c$ with defining rewrite rule $qa\sim c$:
 \[M_3 := \Pres{a,b,c,n,q}{nn\sim n,\, qq\sim q,\, qn\sim q,\, nan\sim na,\,qaq\sim qa,\,na\sim b,\,qa\sim c}\]
-Completion suceeds on $M_3$ using a reduction order where $c<b<a$ and $p<n$, and we get a finite convergent rewrite system. We've already listed the numerous rules once, so we won't do it again. Let's call this finite convergent presentation $M_2^\prime$:
+Completion succeeds on $M_3$ using a reduction order where $c<b<a$ and $p<n$, and we get a finite convergent rewrite system. We've already listed the numerous rules once, so we won't do it again. Let's call this finite convergent presentation $M_2^\prime$:
 \[M_3^\prime := \Pres{a,b,c,n,q}{\mbox{\ldots 15 rewrite rules \ldots}}\]
 The minimized rewrite system corresponds to this presentation:
 \[M_4 :=\Pres{a,b,c,n,q}{nn\sim n,\, na\sim b,\, bn\sim b,\, qq\sim q,\, qa\sim c,\, qn\sim q,\, cq\sim c}\]

docs/Generics/chapters/conformance-paths.tex

@@ -566,7 +566,7 @@ This allows us to define an \IndexDefinition{infinite generic signature}\emph{in
 \begin{proof}
 For $(1)\Rightarrow(2)$, note that the set of generic parameter types is always finite, so it suffices to only consider reduced \index{dependent member type}dependent member types. Suppose we're given an infinite set of reduced dependent member types; we must produce an infinite set of abstract conformances. Each dependent member type \texttt{T.[P]A} is equivalent to an ordered pair consisting of a type witness projection $\AssocType{[P]A}$ and an abstract conformance $\ConfReq{T}{P}$; the first element of the pair is drawn from a finite set, so a counting argument shows that the mapping that takes the second element of each pair must give us an infinite set of abstract conformances.
 
-Furthermore, these abstract conformances must be reduced, meaning their subject types are reduced. To see why, note that whenever \texttt{T.[P]A} is a reduced dependent member type, its base type \texttt{T} must be reduced as well (otherwise, if $G\vDash\SameReq{$\texttt{T}^\prime$}{T}$ with $\texttt{T}^\prime<\texttt{T}$, we could construct from this a derivation of $\SameReq{$\texttt{T}^\prime$.[P]A}{T.[P]A}$ with $\texttt{$\texttt{T}^\prime$.[P]A} < \texttt{T.[P]A}$, contradicting the asumption that \texttt{T.[P]A} is reduced).
+Furthermore, these abstract conformances must be reduced, meaning their subject types are reduced. To see why, note that whenever \texttt{T.[P]A} is a reduced dependent member type, its base type \texttt{T} must be reduced as well (otherwise, if $G\vDash\SameReq{$\texttt{T}^\prime$}{T}$ with $\texttt{T}^\prime<\texttt{T}$, we could construct from this a derivation of $\SameReq{$\texttt{T}^\prime$.[P]A}{T.[P]A}$ with $\texttt{$\texttt{T}^\prime$.[P]A} < \texttt{T.[P]A}$, contradicting the assumption that \texttt{T.[P]A} is reduced).
 
 A similar argument establishes $(2)\Rightarrow(1)$. We're given an infinite set of reduced abstract conformances, and we must produce an infinite set of reduced type parameters. Each abstract conformance $\ConfReq{T}{P}$ uniquely determines an ordered pair, consisting of a \index{protocol declaration}protocol declaration $\protosym{P}$ and a type parameter \texttt{T}. The set of protocol declarations is finite, so again, taking the second element of each pair gives us an infinite set of reduced type parameters.
 \end{proof}

docs/Generics/chapters/declarations.tex

@@ -568,7 +568,7 @@ In a method body, an unqualified reference to a member of the innermost nominal
 
 An unqualified reference to a member of an outer nominal type can only be made if the member is static, because there is no ``outer \texttt{self} value'' to invoke the method with; a \emph{value} of the nested type does not contain a \emph{value} of its parent type.
 
-For the same reason, methods inside \index{local type declaration}local types cannot refer to local variables declared outside of the local type. (Constrast this with \index{Java}Java inner classes for example, which can be declared as \texttt{static} or instance members of their outer class; a non-\texttt{static} inner class captures a ``\texttt{this}'' reference from the outer class. Inner classes nested in methods can also capture local variables in Java.)
+For the same reason, methods inside \index{local type declaration}local types cannot refer to local variables declared outside of the local type. (Contrast this with \index{Java}Java inner classes for example, which can be declared as \texttt{static} or instance members of their outer class; a non-\texttt{static} inner class captures a ``\texttt{this}'' reference from the outer class. Inner classes nested in methods can also capture local variables in Java.)
 
 \paragraph{Constructor declarations.}
 \IndexDefinition{constructor declaration}Constructor declarations are introduced with the \texttt{init} keyword. The parent context of a constructor must be a nominal type or extension.
@@ -1026,7 +1026,7 @@ Operations on type contexts:
 \item \texttt{getSelfInterfaceType()} is similar.
 \end{itemize}
 
-Generic prameters and requirements:
+Generic parameters and requirements:
 \begin{itemize}
 \item \texttt{isGenericContext()} answers true if either this generic context or one of its parents has a generic parameter list.
 \item \texttt{isInnermostContextGeneric()} answers if this declaration context itself has a generic parameter list. Compare with \texttt{isGenericContext()}.

docs/Generics/chapters/extensions.tex

@@ -251,7 +251,7 @@ Nominal type declarations and extensions are \IndexDefinition{iterable declarati
 \paragraph{Member lookup table.}
 Every nominal type declaration has an associated \IndexDefinition{member lookup table}\emph{member lookup table}, which is used for direct lookup. This table maps each identifier to a list of value declarations with that name (multiple value declarations can share a name because Swift allows type-based overloading). The declarations in a member lookup table are understood to be members of one or more iterable declaration contexts, which are exactly the type declaration itself and all of its extensions. These iterable declaration contexts might originate from a mix of different module kinds. For example, the nominal type itself might be an \index{Objective-C}Objective-C class from an imported Objective-C module, with one extension declared in a binary Swift module, and another extension defined in the main module, parsed from source. 
 
-The lookup table is populated lazily, in a manner resembling a state machine. Say we're asked to perform a direct lookup for some given name. If this is the first direct lookup, we populate the member lookup table with \emph{all} members from any \emph{parsed} iterable declaration contexts, which might trigger delayed parsing. Each entry in the member lookup table stores a ``complete'' bit. The ``complete'' bit of these initially-populated entries is \emph{not} set, meaning that the entry only contains those members that were parsed from source. If any iterable declaration contexts originate from binary and imported modules, direct lookup then asks each lazy member loader to selectively load only those members with the given name. (Parsed declaration contexts do not offer this level of lazyness, because there is no way to parse a subset of the members only.) After the lazy member loaders do their work, the lookup table entry for this name is now complete, and the ``complete'' bit is set. Later when direct lookup finds a member lookup table entry with the ``complete'' bit set, it knows this entry is fully populated, and the stored list of declarations is returned immediately without querying the lazy member loaders.
+The lookup table is populated lazily, in a manner resembling a state machine. Say we're asked to perform a direct lookup for some given name. If this is the first direct lookup, we populate the member lookup table with \emph{all} members from any \emph{parsed} iterable declaration contexts, which might trigger delayed parsing. Each entry in the member lookup table stores a ``complete'' bit. The ``complete'' bit of these initially-populated entries is \emph{not} set, meaning that the entry only contains those members that were parsed from source. If any iterable declaration contexts originate from binary and imported modules, direct lookup then asks each lazy member loader to selectively load only those members with the given name. (Parsed declaration contexts do not offer this level of laziness, because there is no way to parse a subset of the members only.) After the lazy member loaders do their work, the lookup table entry for this name is now complete, and the ``complete'' bit is set. Later when direct lookup finds a member lookup table entry with the ``complete'' bit set, it knows this entry is fully populated, and the stored list of declarations is returned immediately without querying the lazy member loaders.
 
 This \emph{lazy member loading} mechanism ensures that only those members which are actually referenced in a compilation session are loaded from serialized and imported iterable declaration contexts.
 

docs/Generics/chapters/generic-signatures.tex

@@ -1377,7 +1377,7 @@ The generic signature queries from \SecRef{genericsigqueries} are methods on \te
 
 \IndexSource{canonical generic signature}
 \apiref{CanGenericSignature}{class}
-The \texttt{CanGenericSignature} class wraps a \texttt{GenericSignatureImpl *} pointer which is known to be canonical. The pointer can be recovered with the \texttt{getPointer()} method. There is an implicit conversion from \texttt{CanGenenericSiganture} to \texttt{GenericSignature}. The \texttt{operator->} forwards method calls to the underlying \texttt{GenericSignatureImpl}.
+The \texttt{CanGenericSignature} class wraps a \texttt{GenericSignatureImpl *} pointer which is known to be canonical. The pointer can be recovered with the \texttt{getPointer()} method. There is an implicit conversion from \texttt{CanGenericSignature} to \texttt{GenericSignature}. The \texttt{operator->} forwards method calls to the underlying \texttt{GenericSignatureImpl}.
 
 The \texttt{operator==} and \texttt{operator!=} operators are used to test \texttt{CanGenericSignature} for pointer equality. The \texttt{isEqual()} method of \texttt{GenericSignatureImpl} implements canonical equality on arbitrary generic signatures by first canonicalizing both sides, then checking the resulting canonical signatures for pointer equality. Therefore, the following are equivalent:
 \begin{Verbatim}

docs/Generics/chapters/monoids.tex

@@ -360,7 +360,7 @@ These give us an \index{infinite monoid presentation}\emph{infinite} presentatio
 \item For every pair of distinct prime numbers $p$ and $q$, we have $p\cdot q\sim q\cdot p$, so our binary operation is commutative.
 \item For every prime number $p$, we have $0\cdot p\sim 0$ and $p\cdot 0\sim 0$, so that zero behaves like  the \index{zero element}zero element.
 \end{itemize}
-In fact, no ``smaller'' presentation exists. It is perhaps surprising to constrast this with $(\mathbb{N},+,0)$, which just the free monoid with one generator.
+In fact, no ``smaller'' presentation exists. It is perhaps surprising to contrast this with $(\mathbb{N},+,0)$, which just the free monoid with one generator.
 \end{example}
 
 \paragraph{Mathematical aside.}

docs/Generics/chapters/symbols-terms-and-rules.tex

@@ -993,7 +993,7 @@ See also \SecRef{completion sourceref}.
 \IndexSource{rule builder}
 collectRulesFromReferencedProtocols() is actually the algorithm from the previous section.
 
-\apiref{rewriting::Trie}{tempalte class}
+\apiref{rewriting::Trie}{template class}
 \IndexSource{trie}
 
 See also \SecRef{completion sourceref}.

docs/Generics/chapters/type-resolution.tex

@@ -464,7 +464,7 @@ protocol Pet {
 func celebratePetBirthday(_ age: Pet.Age) {}
 \end{Verbatim}
 
-Due to pecularities of type substitution, protocol type aliases that are also \index{generic type alias}generic are always considered to depend on \texttt{Self}, even if their underlying type does not reference \texttt{Self}, so they \index{limitation!generic type alias with protocol base}cannot be referenced with a protocol base. (In structural resolution stage, a generic type alias cannot be referenced with a \index{limitation!generic type alias with type parameter base}type parameter base, either. Perhaps it is best not to stick generic type aliases inside protocols, at all.)
+Due to peculiarities of type substitution, protocol type aliases that are also \index{generic type alias}generic are always considered to depend on \texttt{Self}, even if their underlying type does not reference \texttt{Self}, so they \index{limitation!generic type alias with protocol base}cannot be referenced with a protocol base. (In structural resolution stage, a generic type alias cannot be referenced with a \index{limitation!generic type alias with type parameter base}type parameter base, either. Perhaps it is best not to stick generic type aliases inside protocols, at all.)
 
 \paragraph{General principle.} Let's say that $H$ is the generic signature of the current context, and \texttt{T} is the resolved base type of our member type representation, obtained via a recursive call to type resolution. We perform a \index{qualified lookup}qualified lookup after considering the base type \texttt{T}:
 \begin{itemize}

docs/SIL.rst

@@ -3747,7 +3747,7 @@ of ``scalar_pack_index``, ``pack_pack_index``, or ``dynamic_pack_index``),
 and it must index into a pack type with the same shape as the indexed
 pack type.
 
-Third, additional restrictions must be satisifed depending on which
+Third, additional restrictions must be satisfied depending on which
 pack indexing instruction the pack index is:
 
 - For ``scalar_pack_index``, the projected element type must be the

docs/Swift3Compatibility.md

@@ -106,7 +106,7 @@ Any other changes are likely to break clients, even more so if overrides are a p
 - If it's a parameter for a top-level function, a struct or enum method, or a class method you call but don't override, there should be no problem.
 - If it's an index for a subscript you call but don't override, there should be no problem.
 
-Unfortunately, the remaining changes are clearly unsafe, but may still happen because of APIs that were mis-annotated.
+Unfortunately, the remaining changes are clearly unsafe, but may still happen because of APIs that were misannotated.
 
 - If it's a property or a subscript element, this change **breaks source compatibility.**
 - If it's a result type for a top-level function, struct or enum method, or class method, this change **breaks source compatibility.**