diff options
Diffstat (limited to 'compiler')
| -rw-r--r-- | compiler/cmm/CmmImplementSwitchPlans.hs | 2 | ||||
| -rw-r--r-- | compiler/coreSyn/CoreLint.hs | 2 | ||||
| -rw-r--r-- | compiler/ghci/ByteCodeGen.hs | 2 | ||||
| -rw-r--r-- | compiler/prelude/TysPrim.hs | 2 | ||||
| -rw-r--r-- | compiler/prelude/primops.txt.pp | 2 | ||||
| -rw-r--r-- | compiler/simplCore/Simplify.hs | 2 |
6 files changed, 6 insertions, 6 deletions
diff --git a/compiler/cmm/CmmImplementSwitchPlans.hs b/compiler/cmm/CmmImplementSwitchPlans.hs index 225c77e6d6..d378c66168 100644 --- a/compiler/cmm/CmmImplementSwitchPlans.hs +++ b/compiler/cmm/CmmImplementSwitchPlans.hs @@ -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. -- diff --git a/compiler/coreSyn/CoreLint.hs b/compiler/coreSyn/CoreLint.hs index b97f97e88d..089a2250af 100644 --- a/compiler/coreSyn/CoreLint.hs +++ b/compiler/coreSyn/CoreLint.hs @@ -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) diff --git a/compiler/ghci/ByteCodeGen.hs b/compiler/ghci/ByteCodeGen.hs index 5484288a9b..0033df1cea 100644 --- a/compiler/ghci/ByteCodeGen.hs +++ b/compiler/ghci/ByteCodeGen.hs @@ -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 diff --git a/compiler/prelude/TysPrim.hs b/compiler/prelude/TysPrim.hs index cdc25e0fc6..0732b5636d 100644 --- a/compiler/prelude/TysPrim.hs +++ b/compiler/prelude/TysPrim.hs @@ -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 diff --git a/compiler/prelude/primops.txt.pp b/compiler/prelude/primops.txt.pp index a3139202d3..41a725ff51 100644 --- a/compiler/prelude/primops.txt.pp +++ b/compiler/prelude/primops.txt.pp @@ -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 diff --git a/compiler/simplCore/Simplify.hs b/compiler/simplCore/Simplify.hs index e78714daab..1b89f3e394 100644 --- a/compiler/simplCore/Simplify.hs +++ b/compiler/simplCore/Simplify.hs @@ -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) -> ... } |