Correct spelling errors

Reviewers: bgamari, osa1

Reviewed By: osa1

Subscribers: rwbarton, thomie, carter

GHC Trac Issues: #15408

Differential Revision: https://phabricator.haskell.org/D4978

compiler/typecheck/TcUnify.hs

@@ -558,7 +558,7 @@ tcSubTypeET _ _ (Infer inf_res) ty_expected
   = ASSERT2( not (ir_inst inf_res), ppr inf_res $$ ppr ty_expected )
       -- An (Infer inf_res) ExpSigmaType passed into tcSubTypeET never
       -- has the ir_inst field set.  Reason: in patterns (which is what
-      -- tcSubTypeET is used for) do not agressively instantiate
+      -- tcSubTypeET is used for) do not aggressively instantiate
     do { co <- fill_infer_result ty_expected inf_res
                -- Since ir_inst is false, we can skip fillInferResult
                -- and go straight to fill_infer_result
@@ -750,7 +750,7 @@ tc_sub_type_ds eq_orig inst_orig ctxt ty_actual ty_expected
     --    go ty_a (TyVarTy alpha)
     -- which, in the impredicative case unified  alpha := ty_a
     -- where th_a is a polytype.  Not only is this probably bogus (we
-    -- simply do not have decent story for imprdicative types), but it
+    -- simply do not have decent story for impredicative types), but it
     -- caused Trac #12616 because (also bizarrely) 'deriving' code had
     -- -XImpredicativeTypes on.  I deleted the entire case.
 
@@ -907,7 +907,7 @@ has the ir_inst flag.
     f :: forall {a}. a -> forall b. Num b => b -> b -> b
   This is surely confusing for users.
 
-  And worse, the monomorphism restriction won't properly. The MR is
+  And worse, the monomorphism restriction won't work properly. The MR is
   dealt with in simplifyInfer, and simplifyInfer has no way of
   instantiating. This could perhaps be worked around, but it may be
   hard to know even when instantiation should happen.
@@ -1024,7 +1024,7 @@ to
         (forall a. a->a) -> alpha[l+1]
 and emit the constraint
         [W] alpha[l+1] ~ Int
-Now the poromoted type can fill the ref cell, while the emitted
+Now the promoted type can fill the ref cell, while the emitted
 equality can float or not, according to the usual rules.
 
 But that's not quite right!  We are exposing the arrow! We could
@@ -1037,7 +1037,7 @@ Here we abstract over the '->' inside the forall, in case that
 is subject to an equality constraint from a GADT match.
 
 Note that we kept the outer (->) because that's part of
-the polymorphic "shape".  And becauuse of impredicativity,
+the polymorphic "shape".  And because of impredicativity,
 GADT matches can't give equalities that affect polymorphic
 shape.
 
@@ -1662,7 +1662,7 @@ So we look for a positive reason to swap, using a three-step test:
                   on the left because there are fewer
                   restrictions on updating TauTvs
 
-  - SigTv/TauTv:  put on the left eitehr
+  - SigTv/TauTv:  put on the left either
      a) Because it's touchable and can be unified, or
      b) Even if it's not touchable, TcSimplify.floatEqualities
         looks for meta tyvars on the left
@@ -1694,7 +1694,7 @@ Wanteds and Givens, but either way, deepest wins!  Simple.
   If we orient the Given a[2] on the left, we'll rewrite the Wanted to
   (beta[1] ~ b[1]), and that can float out of the implication.
   Otherwise it can't.  By putting the deepest variable on the left
-  we maximise our changes of elminating skolem capture.
+  we maximise our changes of eliminating skolem capture.
 
   See also TcSMonad Note [Let-bound skolems] for another reason
   to orient with the deepest skolem on the left.
@@ -1757,7 +1757,7 @@ where fsk is a flatten-skolem (FlatSkolTv). Suppose we have
 then we'll reduce the second constraint to
      [G] a ~ fsk
 and then replace all uses of 'a' with fsk.  That's bad because
-in error messages intead of saying 'a' we'll say (F [a]).  In all
+in error messages instead of saying 'a' we'll say (F [a]).  In all
 places, including those where the programmer wrote 'a' in the first
 place.  Very confusing!  See Trac #7862.
 
@@ -1997,7 +1997,7 @@ matchExpectedFunKind hs_ty = go
 Suppose we are considering unifying
    (alpha :: *)  ~  Int -> (beta :: alpha -> alpha)
 This may be an error (what is that alpha doing inside beta's kind?),
-but we must not make the mistake of actuallyy unifying or we'll
+but we must not make the mistake of actually unifying or we'll
 build an infinite data structure.  So when looking for occurrences
 of alpha in the rhs, we must look in the kinds of type variables
 that occur there.