[commit: ghc] ghc-8.2: Catch a few more typos in comments (27d6ee3)

[git at git.haskell.org]

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

On branch  : ghc-8.2
Link       : http://ghc.haskell.org/trac/ghc/changeset/27d6ee36337c2da060c74f17e7a63f5f57b8639f/ghc

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

commit 27d6ee36337c2da060c74f17e7a63f5f57b8639f
Author: Gabor Greif <ggreif at gmail.com>
Date:   Mon Oct 30 12:21:49 2017 +0100

    Catch a few more typos in comments
    
    (cherry picked from commit 201b5aa65109e09953caa1dc1774b75fabbf61b0)


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

27d6ee36337c2da060c74f17e7a63f5f57b8639f
 compiler/specialise/SpecConstr.hs     | 4 ++--
 compiler/typecheck/TcCanonical.hs     | 2 +-
 compiler/typecheck/TcInteract.hs      | 4 ++--
 ghc/Main.hs                           | 2 +-
 libraries/base/configure.ac           | 2 +-
 utils/llvm-targets/gen-data-layout.sh | 2 +-
 6 files changed, 8 insertions(+), 8 deletions(-)

diff --git a/compiler/specialise/SpecConstr.hs b/compiler/specialise/SpecConstr.hs
index f686f0f..647f696 100644
--- a/compiler/specialise/SpecConstr.hs
+++ b/compiler/specialise/SpecConstr.hs
@@ -514,7 +514,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
@@ -524,7 +524,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?
 
diff --git a/compiler/typecheck/TcCanonical.hs b/compiler/typecheck/TcCanonical.hs
index 0221a3e..0635b4a 100644
--- a/compiler/typecheck/TcCanonical.hs
+++ b/compiler/typecheck/TcCanonical.hs
@@ -1575,7 +1575,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
diff --git a/compiler/typecheck/TcInteract.hs b/compiler/typecheck/TcInteract.hs
index 5bbc5f8..9af7198 100644
--- a/compiler/typecheck/TcInteract.hs
+++ b/compiler/typecheck/TcInteract.hs
@@ -2009,9 +2009,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
diff --git a/ghc/Main.hs b/ghc/Main.hs
index cc6d08e..5926718 100644
--- a/ghc/Main.hs
+++ b/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
diff --git a/libraries/base/configure.ac b/libraries/base/configure.ac
index 69ea800..f472319 100644
--- a/libraries/base/configure.ac
+++ b/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.])
 ])
diff --git a/utils/llvm-targets/gen-data-layout.sh b/utils/llvm-targets/gen-data-layout.sh
index 95c629c..6f2aafc 100755
--- a/utils/llvm-targets/gen-data-layout.sh
+++ b/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;;