Fix a few typos

docs/AndroidBuild.md

@@ -34,7 +34,7 @@ git clone https://github.com/apple/swift-corelibs-xctest swift-corelibs-xctest
 git clone https://github.com/compnerd/swift-build swift-build
 ```
 
-## 1. Acquire the lastest toolchain and dependencies
+## 1. Acquire the latest toolchain and dependencies
 
 1. Download the toolchain, ICU, libxml2, and curl for android from
    [Azure](https://dev.azure.com/compnerd/swift-build) into `S:\b\a\Library`.

docs/CppInteroperability/CppInteroperabilityManifesto.md

@@ -500,7 +500,7 @@ accepts an address.
 
 C++ has complex overload resolution rules, in part to support certain API design
 patterns. Some API design patterns appeared as a consequence of overload
-resolution rules. Therefore, in C++ an "API atom" is an an overload set, not an
+resolution rules. Therefore, in C++ an "API atom" is an overload set, not an
 individual function ([CppCon 2018: Titus Winters "Modern C++ Design (part 1 of
 2)"](https://www.youtube.com/watch?v=xTdeZ4MxbKo)). The same is also the case in
 Swift, so, fundamentally, there is no impedance mismatch here.
@@ -938,7 +938,7 @@ be handled in Swift.
 
 While it is possible to [propagate C++ exceptions](#exceptions) thrown by normal
 member functions to Swift code, special member functions are different as they
-used used to implement value witnesses, which are called by the compiler
+used to implement value witnesses, which are called by the compiler
 implicitly. Therefore, either such exceptions have to be mapped to fatal errors
 (as we do for other unhandled C++ exceptions), or calls to such special member
 functions must be prevented statically.
@@ -2337,7 +2337,7 @@ different APIs across specializations of the same class. All instantiations of a
 generic type in Swift have the API described in the generic declaration (with
 type parameters substituted), plus applicable conditional extensions.
 
-C++ templates support non-type template parameters, template template
+C++ templates support non-type template parameters, template
 parameters, and parameter packs (variadic generics), all of which are not
 supported in Swift.
 

docs/CppInteroperability/InteropOddities.md

@@ -1,23 +1,23 @@
 # C++ Interoperability Oddities
 
-C++ APIs may have slightly different behavior than other C++ APIs. This is a general catch-all document where these 
+C++ APIs may have slightly different behavior than other C++ APIs. This is a general catch-all document where these
 oddities are recorded along with a few other things that are good to know when using C++ interop.
 
 **Parameters with reference types**
 
-Parameters that have mutable reference types are bridged as inout. Parameters with immutable reference types (const ref) 
-are bridged as value types. ⚠️ This will change as soon as Swift has a way to represent immutable borrows. ⚠️ 
+Parameters that have mutable reference types are bridged as inout. Parameters with immutable reference types (const ref)
+are bridged as value types. ⚠️ This will change as soon as Swift has a way to represent immutable borrows. ⚠️
 
 **Lifetimes**
 
-Currently, lifetimes are extended to the end of the lexical scope if any unsafe pointers are used in that scope. TODO: 
-this should be updated to extend lifetimes whenever a C++ type is used in that scope. Currently, if there is no 
-unsafe pointer used in the scope, then normal Swift lifetime rules apply.   
+Currently, lifetimes are extended to the end of the lexical scope if any unsafe pointers are used in that scope. TODO:
+this should be updated to extend lifetimes whenever a C++ type is used in that scope. Currently, if there is no
+unsafe pointer used in the scope, then normal Swift lifetime rules apply.
 
 **Borrowing Self**
 
-For mutating methods, self is borrowed and the access to self lasts for the duration of the call. For non-mutating 
-methods, the access to self is currently instantanious. ⚠️ In the very near future we plan to borrow self in both cases. 
+For mutating methods, self is borrowed and the access to self lasts for the duration of the call. For non-mutating
+methods, the access to self is currently instantaneous. ⚠️ In the very near future we plan to borrow self in both cases.
 This will be a source breaking change from what native Swift methods do. ⚠️
 
-_More to come soon :)_
+_More to come soon :)_

docs/SILMemoryAccess.md

@@ -293,7 +293,7 @@ scope:
 end_access %access : $*S
 ```
 
-Note that is is possible to have a nested access scope on the address
+Note that it is possible to have a nested access scope on the address
 of a struct field, which may show up as an access of
 struct_element_addr after inlining. The rule is that access
 projections cannot occur outside of the outermost access scope within
@@ -396,7 +396,7 @@ instructions may reference the same variable. To find all global uses,
 the client must independently find all global variable references
 within the function. Clients that need to know which SILValue base was
 discovered during use-def traversal in all cases can make use of
-`AccessStorageWithBase` or `AccessPathWithBase`. 
+`AccessStorageWithBase` or `AccessPathWithBase`.
 
 ### AccessPath