Catch a few more typos in comments

compiler/specialise/SpecConstr.hs

@@ -516,7 +516,7 @@ for nested bindings.  (So really it should be passed around explicitly
 and not stored in ScEnv.)  Trac #14379 turned out to be caused by
    f SPEC x = let g1 x = ...
               in ...
-We force-specialise f (becuase of the SPEC), but that generates a specialised
+We force-specialise f (because of the SPEC), but that generates a specialised
 copy of g1 (as well as the original).  Alas g1 has a nested binding g2; and
 in each copy of g1 we get an unspecialised and specialised copy of g2; and so
 on. Result, exponential.  So the force-spec flag now only applies to one
@@ -526,7 +526,7 @@ Mechanism for this one-level-only thing:
 
  - Switch it on at the call to specRec, in scExpr and scTopBinds
  - Switch it off when doing the RHSs;
-   this can be done very conveneniently in decreaseSpecCount
+   this can be done very conveniently in decreaseSpecCount
 
 What alternatives did I consider?
 

compiler/typecheck/TcCanonical.hs

@@ -1623,7 +1623,7 @@ canEqTyVarTyVar, are these
 
 Note [Avoid unnecessary swaps]
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-If we swap without actually improving matters, we can get an infnite loop.
+If we swap without actually improving matters, we can get an infinite loop.
 Consider
     work item:  a ~ b
    inert item:  b ~ c

compiler/typecheck/TcInteract.hs

@@ -2098,9 +2098,9 @@ favour of alpha.  If we instead had
 then we would unify alpha := gamma1; and kick out the wanted
 constraint.  But when we grough it back in, it'd look like
    [W] TF (gamma1, beta) ~ fuv
-and exactly the same thing would happen again!  Infnite loop.
+and exactly the same thing would happen again!  Infinite loop.
 
-This all sesms fragile, and it might seem more robust to avoid
+This all seems fragile, and it might seem more robust to avoid
 introducing gamma1 in the first place, in the case where the
 actual argument (alpha, beta) partly matches the improvement
 template.  But that's a bit tricky, esp when we remember that the

compiler/typecheck/TcSMonad.hs

@@ -787,7 +787,7 @@ Main Theorem [Stability under extension]
    Suppose we have a "work item"
        a -fw-> t
    and an inert generalised substitution S,
-   ThEN the extended substitution T = S+(a -fw-> t)
+   THEN the extended substitution T = S+(a -fw-> t)
         is an inert generalised substitution
    PROVIDED
       (T1) S(fw,a) = a     -- LHS of work-item is a fixpoint of S(fw,_)
@@ -860,9 +860,9 @@ The idea is that
   - (T3) guarantees (WF2).
 
 * (K2) is about inertness.  Intuitively, any infinite chain T^0(f,t),
-  T^1(f,t), T^2(f,T).... must pass through the new work item infnitely
+  T^1(f,t), T^2(f,T).... must pass through the new work item infinitely
   often, since the substitution without the work item is inert; and must
-  pass through at least one of the triples in S infnitely often.
+  pass through at least one of the triples in S infinitely often.
 
   - (K2a): if not(fs>=fs) then there is no f that fs can rewrite (fs>=f),
     and hence this triple never plays a role in application S(f,a).

compiler/typecheck/TcTyClsDecls.hs

@@ -2395,15 +2395,15 @@ checkValidTyCon tc
         fty1 = dataConFieldType con1 lbl
         lbl = flLabel label
 
-        checkOne (_, con2)    -- Do it bothways to ensure they are structurally identical
+        checkOne (_, con2)    -- Do it both ways to ensure they are structurally identical
             = do { checkFieldCompat lbl con1 con2 res1 res2 fty1 fty2
                  ; checkFieldCompat lbl con2 con1 res2 res1 fty2 fty1 }
             where
                 (_, _, _, res2) = dataConSig con2
                 fty2 = dataConFieldType con2 lbl
 
 checkPartialRecordField :: [DataCon] -> FieldLabel -> TcM ()
--- Check the partial record field selector, and warns.
+-- Checks the partial record field selector, and warns.
 -- See Note [Checking partial record field]
 checkPartialRecordField all_cons fld
   = setSrcSpan loc $

compiler/typecheck/TcType.hs

@@ -961,7 +961,7 @@ on the grounds that the work item might rewrite it. Well, 'a' is certainly
 free in [G] b ~R f a.  But because the role of a type variable ('f' in
 this case) is nominal, the work item can't actually rewrite the inert item.
 Moreover, if we were to kick out the inert item the exact same situation
-would re-occur and we end up with an infninite loop in which each kicks
+would re-occur and we end up with an infinite loop in which each kicks
 out the other (Trac #14363).
 -}
 

ghc/Main.hs

@@ -804,7 +804,7 @@ dumpFastStringStats dflags = do
                          ])
         -- we usually get more "has z-encoding" than "z-encoded", because
         -- when we z-encode a string it might hash to the exact same string,
-        -- which will is not counted as "z-encoded".  Only strings whose
+        -- which is not counted as "z-encoded".  Only strings whose
         -- Z-encoding is different from the original string are counted in
         -- the "z-encoded" total.
   putMsg dflags msg

libraries/base/configure.ac

@@ -69,7 +69,7 @@ if test "$ac_cv_header_poll_h" = yes && test "$ac_cv_func_poll" = yes; then
   AC_DEFINE([HAVE_POLL], [1], [Define if you have poll support.])
 fi
 
-# Linux open file description locks
+# Linux open file descriptor locks
 AC_CHECK_DECL([F_OFD_SETLK], [
   AC_DEFINE([HAVE_OFD_LOCKING], [1], [Define if you have open file descriptor lock support.])
 ])

utils/llvm-targets/gen-data-layout.sh

@@ -44,7 +44,7 @@ function get_cpu_and_attr() {
                     # additional columns for opt and llc flags, we could
                     # pass -float-abi=soft; However ghc will use float
                     # registers unconditionally on arm, and as such true
-                    # soft float with the registered llvm backed will is
+                    # soft float with the registerised llvm backend is
                     # currently not possible.
                     +soft-float-abi) shift 2;;
                     *) ATTR+=("$2"); shift 2;;