Typos in notes and comments [ci skip]

5 files changed, 7 insertions, 7 deletions

diff --git a/compiler/simplCore/OccurAnal.hs b/compiler/simplCore/OccurAnal.hs
index 92c21ada14..6217dc8575 100644
--- a/compiler/simplCore/OccurAnal.hs
+++ b/compiler/simplCore/OccurAnal.hs
@@ -1907,7 +1907,7 @@ A:  Saturated applications:  eg   f e1 .. en
 
     In general, given a call (f e1 .. en) we can propagate one-shot info from
     f's strictness signature into e1 .. en, but /only/ if n is enough to
-    saturate the strictness signature. A stricteness signature like
+    saturate the strictness signature. A strictness signature like
 
     f :: C1(C1(L))LS
 
@@ -1924,10 +1924,10 @@ A:  Saturated applications:  eg   f e1 .. en
 
     then the first argument of f will be called at most once.
 
-A': Non-obviously satuated applications: eg    build (f (\x y -> expensive))
+A': Non-obviously saturated applications: eg    build (f (\x y -> expensive))
 
     In this case, f is only manifestly applied to one argument, so it does not
-    look saturated. So bye the previous point, we should not use its strictness
+    look saturated. So by the previous point, we should not use its strictness
     signature to learn about the one-shotness of \x y. But in this case we can:
 
     build is fully applied, so we may use its strictness signature. From that
diff --git a/compiler/simplCore/Simplify.hs b/compiler/simplCore/Simplify.hs
index a6dbfc1ed4..2ad080dd51 100644
--- a/compiler/simplCore/Simplify.hs
+++ b/compiler/simplCore/Simplify.hs
@@ -2283,7 +2283,7 @@ simplAlts env scrut case_bndr alts cont'
         ; (env1, case_bndr1) <- simplBinder env0 case_bndr
         ; let case_bndr2 = case_bndr1 `setIdUnfolding` evaldUnfolding
               env2       = modifyInScope env1 case_bndr2
-              -- See Note [Case-binder evaluated-ness]
+              -- See Note [Case binder evaluated-ness]
 
         ; fam_envs <- getFamEnvs
         ; (alt_env', scrut', case_bndr') <- improveSeq fam_envs env2 scrut
diff --git a/compiler/typecheck/TcCanonical.hs b/compiler/typecheck/TcCanonical.hs
index 671cb132bf..038b6b9914 100644
--- a/compiler/typecheck/TcCanonical.hs
+++ b/compiler/typecheck/TcCanonical.hs
@@ -443,7 +443,7 @@ mk_superclasses_of rec_clss ev cls tys
   where
     cls_nm     = className cls
     loop_found = not (isCTupleClass cls) && cls_nm `elemNameSet` rec_clss
-                 -- Tuples neveer contribute to recursion, and can be nested
+                 -- Tuples never contribute to recursion, and can be nested
     rec_clss'  = rec_clss `extendNameSet` cls_nm
     this_ct    = CDictCan { cc_ev = ev, cc_class = cls, cc_tyargs = tys
                           , cc_pend_sc = loop_found }
diff --git a/compiler/typecheck/TcHsType.hs b/compiler/typecheck/TcHsType.hs
index 15f6217f90..ef8d84c5cd 100644
--- a/compiler/typecheck/TcHsType.hs
+++ b/compiler/typecheck/TcHsType.hs
@@ -1061,7 +1061,7 @@ Trac #11554 shows this example, which made GHC loop:
   data A :: Type where
     B :: forall (a :: A). P a -> A
 
-In order to check the constructor B, we need have the promoted type A, but in
+In order to check the constructor B, we need to have the promoted type A, but in
 order to get that promoted type, B must first be checked. To prevent looping, a
 TyConPE promotion error is given when tcTyVar checks an ATcTyCon in kind mode.
 Any ATcTyCon is a TyCon being defined in the current recursive group (see data
diff --git a/testsuite/tests/simplCore/should_run/T11731.hs b/testsuite/tests/simplCore/should_run/T11731.hs
index e148507798..f61841e4f5 100644
--- a/testsuite/tests/simplCore/should_run/T11731.hs
+++ b/testsuite/tests/simplCore/should_run/T11731.hs
@@ -10,7 +10,7 @@ wwMe :: Int -> (Int,Int) -> (Int, Int)
 wwMe 0 p =
     let a = fst p
         b = snd p
-        -- This ensure sharing of b, as seen by the demand analyzer
+        -- This ensures sharing of b, as seen by the demand analyzer
 
     in foo p `seq`
        -- This ensures that wwMe is strict in the tuple, but that the tuple