[commit: ghc] master: MkId: Typos in comments (afb7213)

[git at git.haskell.org]

Repository : ssh://git@git.haskell.org/ghc

On branch  : master
Link       : http://ghc.haskell.org/trac/ghc/changeset/afb721390cd506f09ce9f04aa3fb19324c2ae5a0/ghc

>---------------------------------------------------------------

commit afb721390cd506f09ce9f04aa3fb19324c2ae5a0
Author: Ömer Sinan Ağacan <omeragacan at gmail.com>
Date:   Mon Nov 30 21:07:24 2015 -0500

    MkId: Typos in comments


>---------------------------------------------------------------

afb721390cd506f09ce9f04aa3fb19324c2ae5a0
 compiler/basicTypes/MkId.hs | 12 ++++++------
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/compiler/basicTypes/MkId.hs b/compiler/basicTypes/MkId.hs
index 989d797..8223f33 100644
--- a/compiler/basicTypes/MkId.hs
+++ b/compiler/basicTypes/MkId.hs
@@ -106,7 +106,7 @@ There are several reasons why an Id might appear in the wiredInIds:
     result type. -- sof 1/99]
 
 (3) Other error functions (rUNTIME_ERROR_ID) are wired in (a) because
-    the desugarer generates code that mentiones them directly, and
+    the desugarer generates code that mentions them directly, and
     (b) for the same reason as eRROR_ID
 
 (4) lazyId is wired in because the wired-in version overrides the
@@ -390,7 +390,7 @@ mkDataConWorkId wkr_name data_con
         -- even if the data constructor is declared strict
         --      e.g.    data T = MkT !(Int,Int)
         -- Why?  Because the *wrapper* is strict (and its unfolding has case
-        -- expresssions that do the evals) but the *worker* itself is not.
+        -- expressions that do the evals) but the *worker* itself is not.
         -- If we pretend it is strict then when we see
         --      case x of y -> $wMkT y
         -- the simplifier thinks that y is "sure to be evaluated" (because
@@ -655,7 +655,7 @@ dataConSrcToImplBang dflags fam_envs arg_ty
   = HsStrict
 
 
--- | Wrappers/Workser and representation following Unpack/Strictness
+-- | Wrappers/Workers and representation following Unpack/Strictness
 -- decisions
 dataConArgRep
   :: Type
@@ -820,7 +820,7 @@ Because then we'd get an infinite number of arguments.
 Here is a more complicated case:
         data S = MkS {-# UNPACK #-} !T Int
         data T = MkT {-# UNPACK #-} !S Int
-Each of S and T must decide independendently whether to unpack
+Each of S and T must decide independently whether to unpack
 and they had better not both say yes. So they must both say no.
 
 Also behave conservatively when there is no UNPACK pragma
@@ -835,7 +835,7 @@ because Int is non-recursive.
 
 Note [Unpack equality predicates]
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-If we have a GADT with a contructor C :: (a~[b]) => b -> T a
+If we have a GADT with a constructor C :: (a~[b]) => b -> T a
 we definitely want that equality predicate *unboxed* so that it
 takes no space at all.  This is easily done: just give it
 an UNPACK pragma. The rest of the unpack/repack code does the
@@ -993,7 +993,7 @@ mkFCallId dflags uniq fcall ty
 
     strict_sig      = mkClosedStrictSig (replicate arity topDmd) topRes
     -- the call does not claim to be strict in its arguments, since they
-    -- may be lifted (foreign import prim) and the called code doen't
+    -- may be lifted (foreign import prim) and the called code doesn't
     -- necessarily force them. See Trac #11076.
 {-
 ************************************************************************