[commit: ghc] master: Typos in comments (7a25659)

[git at git.haskell.org]

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

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

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

commit 7a25659efc4d22086a9e75dc90e3701c1706c625
Author: Gabor Greif <ggreif at gmail.com>
Date:   Wed Jan 3 16:58:36 2018 +0100

    Typos in comments


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

7a25659efc4d22086a9e75dc90e3701c1706c625
 compiler/coreSyn/CorePrep.hs      | 2 +-
 compiler/coreSyn/CoreUtils.hs     | 4 ++--
 docs/users_guide/glasgow_exts.rst | 2 +-
 utils/gen-dll/Main.hs             | 2 +-
 4 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/compiler/coreSyn/CorePrep.hs b/compiler/coreSyn/CorePrep.hs
index 16f69cc..2bfb558 100644
--- a/compiler/coreSyn/CorePrep.hs
+++ b/compiler/coreSyn/CorePrep.hs
@@ -1085,7 +1085,7 @@ How might it not be evaluated?  Well, we might have floated it out
 of the scope of a `seq`, or dropped the `seq` altogether.
 
 We only do this if 'e' is not a WHNF.  But if it's a simple
-variable (common case) we need to know it's evaluated-ness flag.
+variable (common case) we need to know its evaluated-ness flag.
 Example:
    data T = MkT !Bool
    f v = case v of
diff --git a/compiler/coreSyn/CoreUtils.hs b/compiler/coreSyn/CoreUtils.hs
index d35ae23..fbe7ebd 100644
--- a/compiler/coreSyn/CoreUtils.hs
+++ b/compiler/coreSyn/CoreUtils.hs
@@ -1500,7 +1500,7 @@ But we restrict it sharply:
          _ ->  ...v...v....
   Should v be considered ok-for-speculation?  Its scrutinee may be
   evaluated, but the alternatives are incomplete so we should not
-  evalutate it strictly.
+  evaluate it strictly.
 
   Now, all this is for lifted types, but it'd be the same for any
   finite unlifted type. We don't have many of them, but we might
@@ -1538,7 +1538,7 @@ evaluate them.  Indeed, in general primops are, well, primitive
 and do not perform evaluation.
 
 There is one primop, dataToTag#, which does /require/ a lifted
-argument to be evaluted.  To ensure this, CorePrep adds an
+argument to be evaluated.  To ensure this, CorePrep adds an
 eval if it can't see the argument is definitely evaluated
 (see [dataToTag magic] in CorePrep).
 
diff --git a/docs/users_guide/glasgow_exts.rst b/docs/users_guide/glasgow_exts.rst
index 6704b87..34efbfd 100644
--- a/docs/users_guide/glasgow_exts.rst
+++ b/docs/users_guide/glasgow_exts.rst
@@ -12404,7 +12404,7 @@ Bang patterns and Strict Haskell
 In high-performance Haskell code (e.g. numeric code) eliminating
 thunks from an inner loop can be a huge win.
 GHC supports three extensions to allow the programmer to specify
-use of strict (call-by-value) evalution rather than lazy (call-by-need)
+use of strict (call-by-value) evaluation rather than lazy (call-by-need)
 evaluation.
 
 - Bang patterns (:extension:`BangPatterns`) makes pattern matching and
diff --git a/utils/gen-dll/Main.hs b/utils/gen-dll/Main.hs
index 0383b8e..7cc965b 100644
--- a/utils/gen-dll/Main.hs
+++ b/utils/gen-dll/Main.hs
@@ -85,7 +85,7 @@
 
      In the end we end up with libfoo-pt1.dll, libfoo-pt2.dll and libfoo-pt3.dll
      along with libfoo.dll.a. To the rest of the pipeline the split is
-     completely transparant as -lfoo will just continue to work, and the linker
+     completely transparent as -lfoo will just continue to work, and the linker
      is responsible for populating the IAT (Import Address Table) with the
      actual dlls we need.