A few more typos in non-code
authorGabor Greif <ggreif@gmail.com>
Fri, 19 Feb 2016 11:57:03 +0000 (12:57 +0100)
committerGabor Greif <ggreif@gmail.com>
Fri, 19 Feb 2016 11:57:03 +0000 (12:57 +0100)
compiler/specialise/Specialise.hs
libraries/ghc-prim/GHC/Types.hs
testsuite/tests/profiling/should_run/T5654b.hs

index 443998b..a8380d8 100644 (file)
@@ -766,7 +766,7 @@ Suppose
  * Import Lib(foo) into another module M
  * Call 'foo' at some specialised type in M
 Then you jolly well expect it to be specialised in M.  But what if
-'foo' calls another fuction 'Lib.bar'.  Then you'd like 'bar' to be
+'foo' calls another function 'Lib.bar'.  Then you'd like 'bar' to be
 specialised too.  But if 'bar' is not marked INLINEABLE it may well
 not be specialised.  The warning Opt_WarnMissedSpecs warns about this.
 
index a1aea0b..727811b 100644 (file)
@@ -358,7 +358,7 @@ data type T.  Things to think about
   - We do this for every module (except this module GHC.Types), so we can't
     depend on anything else (eg string unpacking code)
 
-That's why we have these terribly low-level repesentations.  The TrName
+That's why we have these terribly low-level representations.  The TrName
 type lets us use the TrNameS constructor when allocating static data;
 but we also need TrNameD for the case where we are deserialising a TyCon
 or Module (for example when deserialising a TypeRep), in which case we
index 2a00abf..a052141 100644 (file)
@@ -1,5 +1,5 @@
 -- A variant of T5654 where instead of evaluating directly to a
--- funciton, f evaluates to a new PAP.  This exposes a slightly
+-- function, f evaluates to a new PAP.  This exposes a slightly
 -- different but related bug, where when we create a new PAP by
 -- applying arguments to an existing PAP, we should take into account
 -- the stack on the original PAP.