Spelling in comments only [ci skip]
authorGabor Greif <ggreif@gmail.com>
Tue, 28 Mar 2017 09:59:48 +0000 (11:59 +0200)
committerGabor Greif <ggreif@gmail.com>
Tue, 28 Mar 2017 10:18:43 +0000 (12:18 +0200)
compiler/cmm/CmmImplementSwitchPlans.hs
compiler/coreSyn/CoreLint.hs
compiler/ghci/ByteCodeGen.hs
compiler/prelude/TysPrim.hs
compiler/prelude/primops.txt.pp
compiler/simplCore/Simplify.hs
ghc/GHCi/UI.hs
rts/linker/Elf.c
rts/linker/MachO.c
rts/linker/MachOTypes.h

index 225c77e..d378c66 100644 (file)
@@ -21,7 +21,7 @@ import DynFlags
 -- CmmSwitch and returned as a SwitchPlan; here is just the implementation in
 -- terms of Cmm code. See Note [Cmm Switches, the general plan] in CmmSwitch.
 --
--- This division into different modules is both to clearly separte concerns,
+-- This division into different modules is both to clearly separate concerns,
 -- but also because createSwitchPlan needs access to the constructors of
 -- SwitchTargets, a data type exported abstractly by CmmSwitch.
 --
index b97f97e..089a225 100644 (file)
@@ -2198,7 +2198,7 @@ mkScrutMsg var var_ty scrut_ty subst
 
 mkNonDefltMsg, mkNonIncreasingAltsMsg :: CoreExpr -> MsgDoc
 mkNonDefltMsg e
-  = hang (text "Case expression with DEFAULT not at the beginnning") 4 (ppr e)
+  = hang (text "Case expression with DEFAULT not at the beginning") 4 (ppr e)
 mkNonIncreasingAltsMsg e
   = hang (text "Case expression with badly-ordered alternatives") 4 (ppr e)
 
index 5484288..0033df1 100644 (file)
@@ -139,7 +139,7 @@ Note [generating code for top-level string literal bindings]
 Here is a summary on how the byte code generator deals with top-level string
 literals:
 
-1. Top-level string literal bindings are spearted from the rest of the module.
+1. Top-level string literal bindings are separated from the rest of the module.
 
 2. The strings are allocated via iservCmd, in allocateTopStrings
 
index cdc25e0..0732b56 100644 (file)
@@ -235,7 +235,7 @@ mkTemplateTyVarsFrom :: Int -> [Kind] -> [TyVar]
 -- b  with unique (mkAlphaTyVarUnique n+1)
 -- ... etc
 -- Typically called as
---   mkTemplateTyVarsFrom (legth kv_bndrs) kinds
+--   mkTemplateTyVarsFrom (length kv_bndrs) kinds
 -- where kv_bndrs are the kind-level binders of a TyCon
 mkTemplateTyVarsFrom n kinds
   = [ mkTyVar name kind
index a313920..41a725f 100644 (file)
@@ -200,7 +200,7 @@ primop   IntMulMayOfloOp  "mulIntMayOflo#"
    {Return non-zero if there is any possibility that the upper word of a
     signed integer multiply might contain useful information.  Return
     zero only if you are completely sure that no overflow can occur.
-    On a 32-bit platform, the recommmended implementation is to do a
+    On a 32-bit platform, the recommended implementation is to do a
     32 x 32 -> 64 signed multiply, and subtract result[63:32] from
     (result[31] >>signed 31).  If this is zero, meaning that the
     upper word is merely a sign extension of the lower one, no
index e78714d..1b89f3e 100644 (file)
@@ -485,7 +485,7 @@ completeNonRecX top_lvl env is_strict old_bndr new_bndr new_rhs
 {-
 {- No, no, no!  Do not try preInlineUnconditionally in completeNonRecX
    Doing so risks exponential behaviour, because new_rhs has been simplified once already
-   In the cases described by the folowing commment, postInlineUnconditionally will
+   In the cases described by the following comment, postInlineUnconditionally will
    catch many of the relevant cases.
         -- This happens; for example, the case_bndr during case of
         -- known constructor:  case (a,b) of x { (p,q) -> ... }
index b2b54d3..f684bf7 100644 (file)
@@ -920,7 +920,7 @@ runCommands' eh sourceErrorHandler gCmd = gmask $ \unmask -> do
 -- A result of Nothing means there was no more input to process.
 -- Otherwise the result is Just b where b is True if the command succeeded;
 -- this is relevant only to ghc -e, which will exit with status 1
--- if the commmand was unsuccessful. GHCi will continue in either case.
+-- if the command was unsuccessful. GHCi will continue in either case.
 runOneCommand :: (SomeException -> GHCi Bool) -> InputT GHCi (Maybe String)
             -> InputT GHCi (Maybe Bool)
 runOneCommand eh gCmd = do
index e8f6aab..2ce4d3d 100644 (file)
@@ -375,7 +375,7 @@ ocVerifyImage_ELF ( ObjectCode* oc )
    if (ehdr->e_ident[EI_DATA] == ELFDATA2MSB) {
        IF_DEBUG(linker,debugBelch( "Is big-endian\n" ));
    } else {
-       errorBelch("%s: unknown endiannness", oc->fileName);
+       errorBelch("%s: unknown endianness", oc->fileName);
        return 0;
    }
 
index 9fc3c5b..16b712a 100644 (file)
@@ -618,7 +618,7 @@ relocateSection_aarch64(ObjectCode * oc, Section * section)
         return 1;
     /* at this point, we have:
      *
-     * - loaded the sections (potentially into non-continuous memory),
+     * - loaded the sections (potentially into non-contiguous memory),
      *   (in ocGetNames_MachO)
      * - registered exported sybmols
      *   (in ocGetNames_MachO)
@@ -628,7 +628,7 @@ relocateSection_aarch64(ObjectCode * oc, Section * section)
      * - All oc->symbols however should now point at the right place.
      */
 
-    /* we need to care about the explicity addend */
+    /* we need to care about the explicit addend */
     int64_t explicit_addend = 0;
     size_t  nreloc = section->info->macho_section->nreloc;
 
@@ -986,7 +986,7 @@ relocateSection(
                 thing -= value;
                 break;
             default:
-                barf("unkown relocation");
+                barf("unknown relocation");
         }
 
         switch(reloc->r_length)
@@ -1687,7 +1687,7 @@ ocGetNames_MachO(ObjectCode* oc)
      * - EXT and UNDF
      * - EXT and not in the same section.
      *
-     * As sections are not necessarily continuous and can live
+     * As sections are not necessarily contiguous and can live
      * anywhere in the addressable space. This obviously makes
      * sense.  However it took me a while to figure this out.
      */
index 31bfdb4..f78bfca 100644 (file)
@@ -30,7 +30,7 @@ typedef struct scattered_relocation_info MachOScatteredRelocationInfo;
 /* Dealing with nlist symbol entries can become
  * painful.  We'll have our own Symbol struct that
  * mirrors the symbol from the nlist and can carry
- * some more infomration (like addr).
+ * some more information (like addr).
  */
 typedef struct _MachOSymbol {
     SymbolName * name;  /* the name of the symbol. */
@@ -101,7 +101,7 @@ typedef struct _ObjectCodeFormatInfo {
  *
  * These are very similar to the SymbolExtras
  * below.  However the SymbolExtras are allocated
- * per ObejctCode and not per Section.
+ * per ObjectCode and not per Section.
  *
  * TODO: Merge SymbolExtras and Stubs.
  */