Merge pull request swiftlang#22499 from rex4539/fix-typos

CodaFi · web-flow · commit 441c85fe98cb · 2019-02-14T14:11:27.000-05:00
Fix typos
diff --git a/docs/ABI/TypeMetadata.rst b/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,
diff --git a/docs/ABIStabilityManifesto.md b/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).
 
diff --git a/docs/ARCOptimization.rst b/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
diff --git a/docs/CallingConvention.rst b/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.
 
diff --git a/docs/CompilerPerformance.md b/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:
 
diff --git a/docs/Generics.rst b/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
diff --git a/docs/LibraryEvolution.rst b/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:
 
diff --git a/docs/ObjectInitialization.rst b/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.
diff --git a/docs/OptimizationTips.rst b/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.
diff --git a/docs/OptimizerCountersAnalysis.md b/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
diff --git a/docs/OwnershipManifesto.md b/docs/OwnershipManifesto.md
@@ -645,7 +645,7 @@ properties.
 
 In some cases, where desired, the compiler may be able to
 preserve source compatibility and avoid an error by implicitly
-inserting a copy instead.  This likely something we would only
+inserting a copy instead.  This is likely something we would only
 do in a source-compatibility mode.
 
 Static enforcement will be used for:
diff --git a/docs/SIL.rst b/docs/SIL.rst
@@ -2709,7 +2709,7 @@ strong reference type have ownership semantics for the referenced heap
 object. Retain and release operations, however,
 are never implicit in SIL and always must be explicitly performed where needed.
 Retains and releases on the value may be freely moved, and balancing
-retains and releases may deleted, so long as an owning retain count is
+retains and releases may be deleted, so long as an owning retain count is
 maintained for the uses of the value.
 
 All reference-counting operations are defined to work correctly on
@@ -2991,7 +2991,7 @@ Asserts that there exists another reference of the value ``%0`` for the scope
 delineated by the call of this builtin up to the first call of a ``builtin
 "unsafeGuaranteedEnd"`` instruction that uses the second element ``%1.1`` of the
 returned value. If no such instruction can be found nothing can be assumed. This
-assertions holds for uses of the first tuple element of the returned value
+assertion holds for uses of the first tuple element of the returned value
 ``%1.0`` within this scope. The returned reference value equals the input
 ``%0``.
 
@@ -3391,7 +3391,7 @@ separately before the ``partial_apply``. The closure does however take ownership
 of the partially applied arguments; when the closure reference count reaches
 zero, the contained values will be destroyed. If the ``partial_apply`` has a
 ``@noescape`` function type (``partial_apply [on_stack]``) the closure context
-is allocated on the stack and intialized to contain the closed-over values. The
+is allocated on the stack and initialized to contain the closed-over values. The
 closed-over values are not retained, lifetime of the closed-over values must be
 managed separately. The lifetime of the stack context of a ``partial_apply
 [on_stack]`` must be terminated with a ``dealloc_stack``.
diff --git a/docs/SequencesAndCollections.rst b/docs/SequencesAndCollections.rst
@@ -285,7 +285,7 @@ stable indices, the element order within the collection itself is stable; the
 order sometimes does not have a meaning and is not chosen by the code that uses
 the collection, but by the implementation details of the collection itself.)
 
-`MutableCollectionType` protocol allows the to replace a specific element,
+`MutableCollectionType` protocol allows the caller to replace a specific element,
 identified by an index, with another one in the same position.  This capability
 essentially allows to rearrange the elements inside the collection in any
 order, thus types that conform to `MutableCollectionType` can represent
diff --git a/docs/StringManifesto.md b/docs/StringManifesto.md
@@ -895,7 +895,7 @@ difficult to serialize.
 
 The index translation problem has two aspects:
 
-  1. `String` views cannot consume one anothers' indices without a cumbersome
+  1. `String` views cannot consume one another's indices without a cumbersome
     conversion step.  An index into a `String`'s `characters` must be translated
     before it can be used as a position in its `unicodeScalars`.  Although these
     translations are rarely needed, they add conceptual and API complexity.
@@ -1188,7 +1188,7 @@ typealias Substring = StringFacade<StringStorage.SubSequence>
 This design would allow us to de-emphasize lower-level `String` APIs such as
 access to the specific encoding, by putting them behind a `.unicode` property.
 A similar effect in a facade-less design would require a new top-level
-`StringProtocol` playing the role of the facade with an an `associatedtype
+`StringProtocol` playing the role of the facade with an `associatedtype
 Storage : Unicode`.
 
 An interesting variation on this design is possible if defaulted generic
diff --git a/docs/WindowsBuild.md b/docs/WindowsBuild.md
@@ -100,7 +100,7 @@ mklink "%VCToolsInstallDir%\include\module.modulemap" S:\swift\stdlib\public\Pla
 mklink "%VCToolsInstallDir%\include\visualc.apinotes" S:\swift\stdlib\public\Platform\visualc.apinotes
 ```
 
-Warning: Creating the above links usually requires adminstrator privileges. The quick and easy way to do this is to open a second developer prompt by right clicking whatever shortcut you used to open the first one, choosing Run As Administrator, and pasting the above commands into the resulting window. You can then close the privileged prompt; this is the only step which requires elevation.
+Warning: Creating the above links usually requires administrator privileges. The quick and easy way to do this is to open a second developer prompt by right clicking whatever shortcut you used to open the first one, choosing Run As Administrator, and pasting the above commands into the resulting window. You can then close the privileged prompt; this is the only step which requires elevation.
 
 ### 5. Build CMark
 - This must be done from within a developer command prompt. CMark is a fairly
diff --git a/docs/weak.rst b/docs/weak.rst
@@ -412,7 +412,7 @@ Looking at these use-cases, there are two main thrusts:
   Here it is reasonable to expect more user expertise, such that
   power and flexibility should take priority over ease of use.
 
-The second set of use cases should addressed by library types working
+The second set of use cases should be addressed by library types working
 on top of basic runtime support.
 
 The first set of use cases will require more direct language support.
@@ -436,7 +436,7 @@ also adds :code:`capture`, and we may later add more variants, such as
 
 :code:`weak` is an attribute which may be applied to any
 variable-like declaration of reference type :code:`T`.  For
-type-system purposes, the variables behaves like a normal
+type-system purposes, the variable behaves like a normal
 variable of type :code:`Optional<T>`, except:
 
 - it does not maintain a +1 reference count invariant and
