Fix typos

Author: rex4539

docs/ABI/TypeMetadata.rst

@@ -410,7 +410,7 @@ Protocol Descriptor
 ~~~~~~~~~~~~~~~~~~~
 
 Protocol descriptors describe the requirements of a protocol, and act as a
-handle for the protocol itself. The are referenced by `Protocol metadata`_, as
+handle for the protocol itself. They are referenced by `Protocol metadata`_, as
 well as `Protocol Conformance Records`_ and generic requirements. Protocol
 descriptors are only created for non-`@objc` Swift protocols: `@objc` protocols
 are emitted as Objective-C metadata. The layout of Swift protocol descriptors is
@@ -433,7 +433,7 @@ as follows:
   the protocol. The generic requirements themselves follow the fixed part
   of the protocol descriptor.
 - The number of **protocol requirements** in the protocol. The protocol
-  requirements follow the generic reuqirements that form the **requirement
+  requirements follow the generic requirements that form the **requirement
   signature**.
 - A string containing the **associated type names**, a C string comprising the
   names of all of the associated types in this protocol, separated by spaces,

docs/ABIStabilityManifesto.md

@@ -388,7 +388,7 @@ Every existing runtime function will need to be audited for its desirability and
 
 The runtime is also responsible for lazily creating new type metadata entries at run time, either for generic type instantiations or for resilient constructs. Library evolution in general introduces a whole new category of needs from the runtime by making data and metadata more opaque, requiring interaction to be done through runtime APIs. Additionally, ownership semantics may require new runtime APIs or modifications to existing APIs. These new runtime needs are still under investigation [[SR-4352](https://bugs.swift.org/browse/SR-4352)].
 
-There are many potential future directions to open up the ABI and operate on less-opaque data directly, as well a techniques such as call-site caching. These are ABI-additive, and will be interesting to explore in the future.
+There are many potential future directions to open up the ABI and operate on less-opaque data directly, as well as techniques such as call-site caching. These are ABI-additive, and will be interesting to explore in the future.
 
 For a potentially-out-of-date listing of runtime symbols and some details, see the [Runtime docs](https://github.com/apple/swift/blob/master/docs/Runtime.md).
 

docs/ARCOptimization.rst

@@ -162,7 +162,7 @@ Contrasts with Alias Analysis
 
 A common question is what is the difference in between RC Identity analysis and
 alias analysis. While alias analysis is attempting to determine if two memory
-location are the same, RC identity analysis is attempting to determine if
+locations are the same, RC identity analysis is attempting to determine if
 reference counting operations on different values would result in the same
 reference count being read or written to.
 
@@ -544,7 +544,7 @@ optimization? We must consider three areas of concern:
    retain/release counts in the loop? Consider a set of retains and a set of
    releases that we wish to hoist out of a loop. We can only hoist the retain,
    release sets out of the loop if all paths in the given loop region from the
-   entrance to the backedge.  have exactly one retain or release from this set.
+   entrance to the backedge have exactly one retain or release from this set.
 
 4. Any early exits that we must move a retain past or a release by must be
    compensated appropriately. This will be discussed in the next section.
@@ -555,7 +555,7 @@ hoist with safety.
 Compensating Early Exits for Lost Dynamic Reference Counts
 ----------------------------------------------------------
 
-Lets say that we have the following loop canonicalized SIL::
+Let's say that we have the following loop canonicalized SIL::
 
   bb0(%0 : $Builtin.NativeObject):
     br bb1
@@ -579,7 +579,7 @@ Lets say that we have the following loop canonicalized SIL::
   bb6:
     return ...
 
-Can we hoist the retain/release pair here? Lets assume the loop is 3 iterations
+Can we hoist the retain/release pair here? Let's assume the loop is 3 iterations
 and we completely unroll it. Then we have::
 
   bb0:
@@ -667,7 +667,7 @@ exit. Consider the following::
   bb6:
     return ...
 
-Lets unroll this loop::
+Let's unroll this loop::
 
   bb0(%0 : $Builtin.NativeObject):
     br bb1

docs/CallingConvention.rst

@@ -1048,7 +1048,7 @@ opaque range in the maximal aligned storage unit with a mapping from
 that aligned storage unit to an integer of the aligned storage unit's
 size.  Remove any other opaque ranges in the maximal aligned storage
 unit.  Note that this can create overlapping ranges in some cases.
-For this purposes of this calculation, the last maximal aligned
+For the purposes of this calculation, the last maximal aligned
 storage unit should be considered "full", as if the type had an
 infinite amount of empty tail-padding.
 

docs/CompilerPerformance.md

@@ -382,7 +382,7 @@ higher-resolution, more-detailed profile, in practice Instruments will often
 stall out and become unresponsive trying to process the additional detail.
 
 Similarly, be sure that as many applications as possible (especially those with
-debuginfo themselves!) are closed, so that Instruments has has little additional
+debuginfo themselves!) are closed, so that Instruments has little additional
 material to symbolicate as possible. It collects a _whole system profile_ at
 very high resolution, so you want to make its life easy by profiling on a quiet
 machine doing little beyond the task you're interested in.
@@ -645,7 +645,7 @@ compilers on hand while you're working.
     ```
 
   - `-Xfrontend -print-clang-stats`: prints counters associated with the clang
-    AST reader, which is operated as a subsystem fo the swift compiler when
+    AST reader, which is operated as a subsystem of the swift compiler when
     importing definitions from C/ObjC. Its output is added to the end of
     whatever output comes from `-print-stats`, and looks like this:
 

docs/Generics.rst

@@ -783,7 +783,7 @@ protocols. A value of an existential type (say, Comparable) is a pair (value,
 vtable). 'value' stores the current value either directly (if it fits in the 3
 words allocated to the value) or as a pointer to the boxed representation (if
 the actual representation is larger than 3 words). By itself, this value cannot
-be interpreted, because it's type is not known statically, and may change due to
+be interpreted, because its type is not known statically, and may change due to
 assignment. The vtable provides the means to manipulate the value, because it
 provides a mapping between the protocols to which the existential type conforms
 (which is known statically) to the functions that implements that

docs/LibraryEvolution.rst

@@ -1135,7 +1135,7 @@ Operators and Precedence Groups
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 Operator and precedence group declarations are entirely compile-time
-constructs, so changing them does not have any affect on binary compatibility.
+constructs, so changing them does not have any effect on binary compatibility.
 However, they do affect *source* compatibility, so it is recommended that
 existing operators are not changed at all except for the following:
 

docs/ObjectInitialization.rst

@@ -117,7 +117,7 @@ Initialization proceeds in several steps:
 2. ``B``'s initializer initializes the stored property ``d`` to
    ``17.0``.
 3. ``B``'s initializer chains to ``A``'s initializer.
-4. ``A``'s initializer initialize's the stored properties ``i`` and
+4. ``A``'s initializer initializes the stored properties ``i`` and
    ``s``'.
 5. ``A``'s initializer calls ``completeInit()``, then returns.
 6. ``B``'s initializer calls ``completeInitForB()``, then returns.
@@ -191,7 +191,7 @@ Initialization proceeds as follows:
    ``d`` to ``17.0``.
 5. ``B``'s designated initializer chains to ``A``'s designated
    initializer.
-6. ``A``'s designated initializer initialize's the stored properties
+6. ``A``'s designated initializer initializes the stored properties
    ``i`` and ``s``'.
 7. ``A``'s designated initializer calls ``completeInit()``, then
    returns.

docs/OptimizationTips.rst

@@ -184,7 +184,7 @@ that value types cannot be included inside an NSArray. Thus when using value
 types, the optimizer can remove most of the overhead in Array that is necessary
 to handle the possibility of the array being backed an NSArray.
 
-Additionally, In contrast to reference types, value types only need reference
+Additionally, in contrast to reference types, value types only need reference
 counting if they contain, recursively, a reference type. By using value types
 without reference types, one can avoid additional retain, release traffic inside
 Array.

docs/OptimizerCountersAnalysis.md

@@ -1,6 +1,6 @@
 # Optimizer Counter Analysis
 
-It is possible possible by means of providing some special command-line
+It is possible by means of providing some special command-line
 options to ask the Swift compiler to produce different statistics about
 the optimizer counters. Optimizer counters are most typically counters
 representing different aspects of a SIL representation for a Swift module