Fix typos in comments

Author: memecoinbeliever

docs/CppInteroperabilityManifesto.md

@@ -307,7 +307,7 @@ provide the following guarantees:
 
 - `inout` are backed by initialized memory on function entry and function exit
   (an implication of the copy-in/copy-out semantics). Destroying the object in
-  `inout` requires using unsafe construts. Therefore, in safe Swift `inout`
+  `inout` requires using unsafe constructs. Therefore, in safe Swift `inout`
   parameters are backed by initialized memory throughout function execution.
 
 - `inout` parameters don't alias each other or any other values that program is
@@ -1033,7 +1033,7 @@ in all Swift code, but it is feasible for local variables of concrete types.
 An example where it is not possible to maintain precise destruction semantics
 for C++ classes is in a generic Swift function that is called with a C++ class
 as a type parameter. In this case, we must be able to compile one definition of
-a Swift function, which must work regradless of the nature of the type (be it a
+a Swift function, which must work regardless of the nature of the type (be it a
 Swift type or a C++ class). This limitation does not seem too bad, because RAII
 types are not often passed as type parameters to templates in C++, which creates
 a reason to believe it will not be common in Swift either.

docs/Diagnostics.md

@@ -100,7 +100,7 @@ Educational notes should:
 - Explain a single language concept. This makes them easy to reuse across related diagnostics and helps keep them clear, concise, and easy to understand.
 - Be written in unabbreviated English. These are longer-form messages compared to the main diagnostic, so there's no need to omit needless words and punctuation.
 - Not generally exceed 3-4 paragraphs. Educational notes should be clear and easily digestible. Messages which are too long also have the potential to create UX issues on the command line.
-- Be accessible. Educational notes should be beginner friendly and avoid assuming unnecesary prior knowledge. The goal is not only to help users understand what a diagnostic is telling them, but also to turn errors and warnings into "teachable moments".
+- Be accessible. Educational notes should be beginner friendly and avoid assuming unnecessary prior knowledge. The goal is not only to help users understand what a diagnostic is telling them, but also to turn errors and warnings into "teachable moments".
 - Include references to relevant chapters of _The Swift Programming Language_.
 - Be written in Markdown, but avoid excessive markup which negatively impacts the terminal UX.
 

docs/DifferentiableProgramming.md

@@ -2542,7 +2542,7 @@ As defined above, the `@differentiable` function type attributes requires all
 non-`@noDerivative` arguments and results to conform to the `@differentiable`
 attribute. However, there is one exception: when the type of an argument or
 result is a function type, e.g. `@differentiable (T) -> @differentiable (U) ->
-V`. This is because we need to differentiate higher-order funtions.
+V`. This is because we need to differentiate higher-order functions.
 
 Mathematically, the differentiability of `@differentiable (T, U) -> V` is
 similar to that of `@differentiable (T) -> @differentiable (U) -> V` in that

include/swift/AST/Decl.h

@@ -2637,7 +2637,7 @@ class TypeAliasDecl : public GenericTypeDecl {
   UnboundGenericType *getUnboundGenericType() const;
 
   /// Retrieve a sugared interface type containing the structure of the interface
-  /// type before any semantic validation has occured.
+  /// type before any semantic validation has occurred.
   Type getStructuralType() const;
 
   /// Whether the typealias forwards perfectly to its underlying type.

lib/IRGen/IRGenDebugInfo.h

@@ -79,7 +79,7 @@ class IRGenDebugInfo {
   /// If we are not emitting CodeView, this does nothing since the ``llvm.trap``
   /// instructions should already have an artificial location of zero.
   /// In CodeView, since zero is not an artificial location, we emit the
-  /// location of the unified trap block at the end of the fuction as an
+  /// location of the unified trap block at the end of the function as an
   /// artificial inline location pointing to the user's instruction.
   void setInlinedTrapLocation(IRBuilder &Builder, const SILDebugScope *Scope);
 

stdlib/include/llvm/Support/MathExtras.h

@@ -881,7 +881,7 @@ extern const float huge_valf;
 
 
 /// Add two signed integers, computing the two's complement truncated result,
-/// returning true if overflow occured.
+/// returning true if overflow occurred.
 template <typename T>
 std::enable_if_t<std::is_signed<T>::value, T> AddOverflow(T X, T Y, T &Result) {
 #if __has_builtin(__builtin_add_overflow)

test/SILOptimizer/funcsig_explode_heuristic.sil

@@ -40,7 +40,7 @@ sil @guaranteed_user : $@convention(thin) (@guaranteed Klass) -> ()
 ///////////
 
 // We should never optimize this. If we did this would become a thunk, so we
-// know that just be checking NFC we have proven no optimization has occured.
+// know that just be checking NFC we have proven no optimization has occurred.
 //
 // CHECK-LABEL: sil @never_explode_trivial : $@convention(thin) (BigTrivial) -> () {
 // CHECK: } // end sil function 'never_explode_trivial'