typo and spelling fixes

Author: vicky002

docs/ErrorHandling.rst

@@ -256,7 +256,7 @@ Throwing an error
 -----------------
 
 The ``throw`` statement begins the propagation of an error.  It always
-take an argument, which can be any value that conforms to the
+takes an argument, which can be any value that conforms to the
 ``ErrorType`` protocol (described below).
 
 ::
@@ -680,7 +680,7 @@ can be overloaded on whether its argument closure throws; the
 overload that takes a throwing closures would itself throw.
 
 There is one minor usability problem here, though.  If the closure
-contains throwing expressions, those expression must be explicitly
+contains throwing expressions, those expressions must be explicitly
 marked within the closure with ``try``.  However, from the compiler's
 perspective, the call to ``autoreleasepool`` is also a call that
 can throw, and so it must also be marked with ``try``::

docs/ErrorHandlingRationale.rst

@@ -26,7 +26,7 @@ The most important dimensions of variation are:
   errors or not; such a language has **typed propagation**.
 
 * Whether, in a language with typed propagation, the default rule is
-  that that a function can produce an error or that it can't; this
+  that a function can produce an error or that it can't; this
   is the language's **default propagation rule**.
 
 * Whether, in a language with typed propagation, the language enforces
@@ -812,7 +812,7 @@ in a very unsafe way that does not behave well in the presence of
 inlining.
 
 Overall, this approach requires a lot of work in the non-error path
-of functions with interesting frames.  Given that we expects functions
+of functions with interesting frames.  Given that we expect functions
 with interesting frames to be very common in Swift, this is not
 an implementation approach we would consider in the abstract.  However,
 it is the implementation approach for C++/ObjC exceptions on iOS/ARM32,
@@ -955,7 +955,7 @@ This allows the defer action to be written near the code it
 "balances", allowing the reader to immediately see that the required
 clean-up will be done (but this has drawbacks, as discussed above).
 It's very compact, which is nice as most defer actions are short.  It
-also allow multiple actions to pile up without adding awkward nesting.
+also allows multiple actions to pile up without adding awkward nesting.
 However, the function-exit semantics exacerbate the problem of
 searching for intervening clean-up actions, and they introduce
 semantic and performance problems with capturing the values of local
@@ -1396,7 +1396,7 @@ same glance.  The keyword appears before the arrow for the simple
 reason that the arrow is optional (along with the rest of the return
 type) in function and initializer declarations; having the keyword
 appear in slightly different places based on the presence of a return
-type would be silly and would making adding a non-void return type
+type would be silly and would make adding a non-void return type
 feel awkward.  The keyword itself should be descriptive, and it's
 particularly nice for it to be a form of the verb used by the throwing
 expression, conjugated as if performed by the function itself.  Thus,

docs/archive/LangRef.html

@@ -786,7 +786,7 @@ <h4 id="attribute-inout"><tt>inout</tt> Attribute</h4>
   </p>
 
   <p><tt>inout</tt> indicates that the argument will be passed as an "in-out"
-    parameter. The caller must pass an lvalue decorated with the <tt>&</tt>
+    parameter. The caller must pass an lvalue decorated with the <tt>&amp;</tt>
     prefix operator as the argument. Semantically, the value of the argument
     is passed "in" to the callee to a local value, and that local value is
     stored back "out" to the lvalue when the callee exits. This is normally
@@ -837,7 +837,7 @@ <h4 id="attribute-inout"><tt>inout</tt> Attribute</h4>
   </pre>
 
   <p>The type being annotated must be <a href="#materializable">materializable</a>.
-    The type after annotation is never materializable.</tt>
+    The type after annotation is never materializable.
 
   <p>FIXME: we probably need a const-like variant, which permits
     r-values (and avoids writeback when the l-value is not physical).

docs/proposals/Accessors.rst

@@ -1027,7 +1027,7 @@ summary of the rule being proposed.
 
 If storage is passed to an ``inout`` argument, then any other
 simultaneous attempt to read or write to that storage, including to
-the storage containing it, will have have unspecified behavior.  Reads
+the storage containing it, will have unspecified behavior.  Reads
 from it may see partially-updated values, or even values which will
 change as modifications are made to the original storage; and writes
 may be clobbered or simply disappear.

docs/proposals/AttrC.rst

@@ -66,7 +66,7 @@ On Darwin, we can allow passing reference counted pointers directly
 as function parameters. They are still not allowed as fields in ``@c``
 structs, though.
 
-The convention for arguments and results an be the same as CoreFoundation
+The convention for arguments and results can be the same as CoreFoundation
 functions imported from C. The code in ``CFunctionConventions`` in
 SILFunctionType.cpp looks relevant.
 

docs/proposals/Concurrency.rst

@@ -202,7 +202,7 @@ variables and unsafe code. Objective-C methods are automatically marked as
 that do not explicitly mark the APIs as reentrant or non-reentrant.
 
 In the example program below the method `fly` may access the global variable
-because it is marked with the attribute `unsafe`. The compile won't allow this
+because it is marked with the attribute `unsafe`. The compiler won't allow this
 method to be executed from a worker-thread.
 
 .. code-block:: swift

docs/proposals/OptimizerEffects.rst

@@ -562,7 +562,7 @@ generic arguments::
     func setElt(elt: T) { t = elt }
   }
 
-With no knowledge of T.deinit() we must assume worst case. SIL effects
+With no knowledge of T.deinit() we must assume the worst case. SIL effects
 analysis following specialization can easily handle such a trivial
 example. But there are two situations to be concerned about:
 
@@ -853,7 +853,7 @@ values, and (3) no calls are made into nonpure code.
     type definition, or it may rely on a type constraint.
 
 (3) Naturally, any calls within the function body must be transitively
-    pure. There is no need to check a calls to the storage
+    pure. There is no need to check calls to the storage
     deinitializer, which should already be guaranteed pure by virtue
     of (2).