Fix typos in documentation

docs/ErrorHandlingRationale.rst

@@ -173,7 +173,7 @@ be quite amazing for us to assert that code shouldn't be written that
 way, understanding nothing else about it.  As long as programmers do
 face these issues, the language has some responsibility to help them.
 
-Therefore, in my judgement, promoting the use of universal errors is
+Therefore, in my judgment, promoting the use of universal errors is
 highly problematic.  They undermine the easy comprehension of code,
 and they undermine the language's ability to help the programmer
 reason about errors.  This design will instead focus on explicitly
@@ -577,7 +577,7 @@ they produce, and so many errors just end up falling into broad
 buckets.  Different libraries end up with their own library-specific
 general error classes, and exceptions list end up just restating the
 library's own dependencies or wrapping the underlying errors in ways
-that loses criticial information.
+that loses critical information.
 
 
 Tradeoffs of typed propagation

docs/HighLevelSILOptimizations.rst

@@ -335,13 +335,13 @@ readwrite
 Optimize semantics attribute
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
-The optimize attribute adds function-sepcific directives to the optimizer.
+The optimize attribute adds function-specific directives to the optimizer.
 
 The optimize attribute supports the following tags:
 
 sil.never
 
-   The sil optimizer should not optimize this funciton.
+   The sil optimizer should not optimize this function.
 
   Example:
   @_semantics("optimize.sil.never")

docs/Pattern Matching.rst

@@ -26,7 +26,7 @@ Swift has a pretty small set of types right now:
 * Function types.
 * Tuples. Heterogeneous fixed-length products. Swift's system
   provides two basic kinds of element: positional and labelled.
-* Arrays. Homogenous fixed-length aggregates.
+* Arrays. Homogeneous fixed-length aggregates.
 * Algebraic data types (ADTs), introduce by enum.  Nominal closed
   disjoint unions of heterogeneous types.
 * Struct types.  Nominal heterogeneous fixed-length products.

docs/StdlibRationales.rst

@@ -159,7 +159,7 @@ functions don't return lazy collection wrappers that refer to users' closures.
 The consequence is that all users' closures are ``@noescape``, except in an
 explicitly lazy context.
 
-Based on this rule, we conclude that ``enumeraate()``, ``zip()`` and
+Based on this rule, we conclude that ``enumerate(), ``zip()`` and
 ``reverse()`` return lazy wrappers, but ``filter()`` and ``map()`` don't.  For
 the first three functions being lazy is the right default, since usually the
 result is immediately consumed by for-in, so we don't want to allocate memory

docs/archive/Objective-C Interoperability.rst

@@ -320,7 +320,7 @@ Methods marked as "overrideable API" only have Objective-C entry points:
 - Less to think about, maximum compatibility.
 - Penalizes future Swift clients (and potentially Objective-C clients?).
 
-Methods marked as "overrideable API" have both Objective-C and Swift entry 
+Methods marked as "overridable API" have both Objective-C and Swift entry 
 points:
 
 - Requires teaching Clang to emit Swift vtables.

docs/doxygen.cfg.in

@@ -385,7 +385,7 @@ SHOW_DIRECTORIES       = YES
 # version control system). Doxygen will invoke the program by executing (via 
 # popen()) the command <command> <input-file>, where <command> is the value of 
 # the FILE_VERSION_FILTER tag, and <input-file> is the name of an input file 
-# provided by doxygen. Whatever the progam writes to standard output 
+# provided by doxygen. Whatever the program writes to standard output 
 # is used as the file version. See the manual for examples.
 
 #FILE_VERSION_FILTER    = 
@@ -418,7 +418,7 @@ WARN_IF_UNDOCUMENTED   = NO
 
 WARN_IF_DOC_ERROR      = YES
 
-# This WARN_NO_PARAMDOC option can be abled to get warnings for 
+# This WARN_NO_PARAMDOC option can be enabled to get warnings for 
 # functions that are documented, but have no documentation for their parameters 
 # or return value. If set to NO (the default) doxygen will only warn about 
 # wrong or incomplete parameter documentation, but not about the absence of 

docs/proposals/Accessors.rst

@@ -1296,7 +1296,7 @@ Code generation patterns
 The signatures and access patterns for addressors will need to change
 in order to ensure memory-safety.
 
-``mutableAddress`` currentlys returns an ``UnsafeMutablePointer``; it
+``mutableAddress`` currently returns an ``UnsafeMutablePointer``; it
 will need to return ``(Builtin.NativeObject?, UnsafeMutablePointer)``.
 The owner pointer must be a native object; we cannot efficiently
 support either uniqueness checking or the NSM bit on non-Swift

docs/proposals/ArrayBridge.rst

@@ -71,7 +71,7 @@ significant.  For example, the design above would pose significant performance
 problems for arrays of integers, because every subscript operation would have to
 check to see if the representation is an NSArray, realize it is not, then do the
 constant time index into the native representation.  Beyond requiring an extra
-check, this check would disable optimizations that can provide a signficant
+check, this check would disable optimizations that can provide a significant
 performance win (like auto-vectorization).
 
 However, the inherent limitations of ``NSArray`` mean that we can

docs/proposals/AttrC.rst

@@ -4,7 +4,7 @@ Eventually, we would like to write Swift modules which define pure-C entry
 points for top-level functions, and be able to export more data types to
 C code.
 
-This will be imporant for the Linux port, but also perhaps for system
+This will be important for the Linux port, but also perhaps for system
 frameworks that want to transition to Swift.
 
 The radars tracking this work are:
@@ -59,7 +59,7 @@ and "non-POD". POD types include:
 
 On Linux, we can't have reference counted pointers here at all, and
 NSArray, etc do not exist, so only POD types are bridgeable. We must
-ensure that we produce ther right diagnostic and not crash when the
+ensure that we produce the right diagnostic and not crash when the
 user references NSArray, etc on Linux.
 
 On Darwin, we can allow passing reference counted pointers directly

docs/proposals/Concurrency.rst

@@ -629,7 +629,7 @@ use actors can scale to support millions of concurrent actors because actors are
 not backed by a live thread or by a stack.
 
 In Swift actors could be implemented using classes that inherit from the generic
-``Actor`` class.  The generic parameter determins the type of messages that the
+``Actor`` class.  The generic parameter determines the type of messages that the
 actor can accept. The message type needs to be of ``CopyableType`` to ensure the
 safety of the model.  The actor class exposes two methods: ``send`` and
 ``accept``. Messages are sent to actors using the ``send`` method and they never

docs/proposals/DeclarationTypeChecker.rst

@@ -176,7 +176,7 @@ How do we measure progress?
 
 The proposed change is a major architectural shift, and it's only complete when we have eliminated all ad hoc recursion from the front end. There are a few ways in which we can measure progress along the way:
 
-**AST nodes that implement the phase-aware trait**: Eventually, all of our AST nodes will implement the phase-aware trait. The number of AST nodes that do properly implement that trait (reporting current phase, enumerating dependencies for a phase transition) and become part of the dependency graph and priorty queue gives an indication of how far we've gotten.
+**AST nodes that implement the phase-aware trait**: Eventually, all of our AST nodes will implement the phase-aware trait. The number of AST nodes that do properly implement that trait (reporting current phase, enumerating dependencies for a phase transition) and become part of the dependency graph and priority queue gives an indication of how far we've gotten.
 
 **Accessors that check the current phase**: When we're finished, each of the AST's accessors should assert that the AST node is in the appropriate phase. The number of such assertions that have been enabled is an indication of how well the type checker is respecting the dependencies.
 

docs/proposals/InoutCOWOptimization.rst

@@ -7,7 +7,7 @@
 :Authors: Dave Abrahams, Joe Groff
 
 :Summary: Our writeback model interacts with Copy-On-Write (COW) to
-          cause some surprising ineffiencies, such as O(N) performance
+          cause some surprising inefficiencies, such as O(N) performance
           for ``x[0][0] = 1``. We propose a modified COW optimization
           that recovers O(1) performance for these cases and supports
           the efficient use of slices in algorithm implementation.

docs/proposals/ObjC Interoperation.rst

@@ -330,7 +330,7 @@ difference between a stored property and its underlying storage,
 For another example, code 
 class might access 
 
-In bot hcaess, t makes sense to organize the code that way,
+In both cases, t makes sense to organize the code that way,
 but Objective C punishes the performance of that code in order to
 reserve the language's