diff options
Diffstat (limited to 'compiler')
64 files changed, 249 insertions, 249 deletions
diff --git a/compiler/GHC/Hs/Expr.hs b/compiler/GHC/Hs/Expr.hs index 9955efaeb1..13ca6b0eff 100644 --- a/compiler/GHC/Hs/Expr.hs +++ b/compiler/GHC/Hs/Expr.hs @@ -2572,7 +2572,7 @@ data ArithSeqInfo id | FromThenTo (LHsExpr id) (LHsExpr id) (LHsExpr id) --- AZ: Sould ArithSeqInfo have a TTG extension? +-- AZ: Should ArithSeqInfo have a TTG extension? instance OutputableBndrId p => Outputable (ArithSeqInfo (GhcPass p)) where diff --git a/compiler/GHC/Hs/Pat.hs b/compiler/GHC/Hs/Pat.hs index d8ae451ee9..bb319181d3 100644 --- a/compiler/GHC/Hs/Pat.hs +++ b/compiler/GHC/Hs/Pat.hs @@ -686,7 +686,7 @@ isIrrefutableHsPat :: (OutputableBndrId p) => LPat (GhcPass p) -> Bool -- Specifically on a ConPatIn, which is what it sees for a -- (LPat Name) in the renamer, it doesn't know the size of the -- constructor family, so it returns False. Result: only --- tuple patterns are considered irrefuable at the renamer stage. +-- tuple patterns are considered irrefutable at the renamer stage. -- -- But if it returns True, the pattern is definitely irrefutable isIrrefutableHsPat diff --git a/compiler/GHC/Platform/Regs.hs b/compiler/GHC/Platform/Regs.hs index fe6588d067..c304d4f5ad 100644 --- a/compiler/GHC/Platform/Regs.hs +++ b/compiler/GHC/Platform/Regs.hs @@ -42,7 +42,7 @@ callerSaves platform -- The order matters (for the llvm backend anyway)! We must make sure to -- maintain the order here with the order used in the LLVM calling conventions. -- Note that also, this isn't all registers, just the ones that are currently --- possbily mapped to real registers. +-- possibly mapped to real registers. activeStgRegs :: Platform -> [GlobalReg] activeStgRegs platform | platformUnregisterised platform = NoRegs.activeStgRegs diff --git a/compiler/GHC/StgToCmm/Bind.hs b/compiler/GHC/StgToCmm/Bind.hs index 3eeb575da7..b1cb34ace7 100644 --- a/compiler/GHC/StgToCmm/Bind.hs +++ b/compiler/GHC/StgToCmm/Bind.hs @@ -198,7 +198,7 @@ cgRhs :: Id CgIdInfo -- The info for this binding , FCode CmmAGraph -- A computation which will generate the -- code for the binding, and return an - -- assignent of the form "x = Hp - n" + -- assignment of the form "x = Hp - n" -- (see above) ) diff --git a/compiler/GHC/StgToCmm/ExtCode.hs b/compiler/GHC/StgToCmm/ExtCode.hs index be2592edd3..4a5225eec6 100644 --- a/compiler/GHC/StgToCmm/ExtCode.hs +++ b/compiler/GHC/StgToCmm/ExtCode.hs @@ -102,7 +102,7 @@ instance HasDynFlags CmmParse where return (d, dflags)) --- | Takes the variable decarations and imports from the monad +-- | Takes the variable declarations and imports from the monad -- and makes an environment, which is looped back into the computation. -- In this way, we can have embedded declarations that scope over the whole -- procedure, and imports that scope over the entire module. diff --git a/compiler/GHC/StgToCmm/Prim.hs b/compiler/GHC/StgToCmm/Prim.hs index 85924d984e..51efe44a42 100644 --- a/compiler/GHC/StgToCmm/Prim.hs +++ b/compiler/GHC/StgToCmm/Prim.hs @@ -2159,7 +2159,7 @@ vecElemProjectCast _ _ _ = Nothing -- values! -- The current design with respect to register mapping of scalars could -- very well be the best,but exploring the design space and doing careful --- measurments is the only only way to validate that. +-- measurements is the only only way to validate that. -- In some next generation CPU ISAs, notably RISC V, the SIMD extension -- includes support for a sort of run time CPU dependent vectorization parameter, -- where a loop may act upon a single scalar each iteration OR some 2,4,8 ... diff --git a/compiler/basicTypes/OccName.hs b/compiler/basicTypes/OccName.hs index fa259725cf..1b25f08c2b 100644 --- a/compiler/basicTypes/OccName.hs +++ b/compiler/basicTypes/OccName.hs @@ -582,7 +582,7 @@ mk_deriv occ_sp sys_prefix str = mkOccNameFS occ_sp (concatFS $ sys_prefix : str) isDerivedOccName :: OccName -> Bool --- ^ Test for definitions internally generated by GHC. This predicte +-- ^ Test for definitions internally generated by GHC. This predicate -- is used to suppress printing of internal definitions in some debug prints isDerivedOccName occ = case occNameString occ of diff --git a/compiler/basicTypes/VarSet.hs b/compiler/basicTypes/VarSet.hs index 2cf15eb3e5..c3b25970f2 100644 --- a/compiler/basicTypes/VarSet.hs +++ b/compiler/basicTypes/VarSet.hs @@ -319,7 +319,7 @@ seqDVarSet s = sizeDVarSet s `seq` () extendDVarSetList :: DVarSet -> [Var] -> DVarSet extendDVarSetList = addListToUniqDSet --- | Convert a DVarSet to a VarSet by forgeting the order of insertion +-- | Convert a DVarSet to a VarSet by forgetting the order of insertion dVarSetToVarSet :: DVarSet -> VarSet dVarSetToVarSet = unsafeUFMToUniqSet . udfmToUfm . getUniqDSet diff --git a/compiler/cmm/CmmBuildInfoTables.hs b/compiler/cmm/CmmBuildInfoTables.hs index 9dc66a44e1..81c86fdad5 100644 --- a/compiler/cmm/CmmBuildInfoTables.hs +++ b/compiler/cmm/CmmBuildInfoTables.hs @@ -227,7 +227,7 @@ implemented. case, if the closure is not locally defined then we can't point to it directly from the info table, because this is the text section which cannot contain runtime relocations. In this case we skip this - optimisation and generate the singleton SRT, becase SRTs are in the + optimisation and generate the singleton SRT, because SRTs are in the data section and *can* have relocatable references. 2. [FUN] A static function closure can also be an SRT, we simply put diff --git a/compiler/cmm/CmmMachOp.hs b/compiler/cmm/CmmMachOp.hs index f8b7d4fb74..418ebec13f 100644 --- a/compiler/cmm/CmmMachOp.hs +++ b/compiler/cmm/CmmMachOp.hs @@ -135,7 +135,7 @@ data MachOp | MO_VU_Quot Length Width | MO_VU_Rem Length Width - -- Floting point vector element insertion and extraction operations + -- Floating point vector element insertion and extraction operations | MO_VF_Insert Length Width -- Insert scalar into vector | MO_VF_Extract Length Width -- Extract scalar from vector diff --git a/compiler/cmm/CmmNode.hs b/compiler/cmm/CmmNode.hs index 1b387020f5..f9bad961e6 100644 --- a/compiler/cmm/CmmNode.hs +++ b/compiler/cmm/CmmNode.hs @@ -715,7 +715,7 @@ isTickSubScope = cmp cmp (SubScope u s) s'@(SubScope u' _) = u == u' || cmp s s' -- | Combine two tick scopes. The new scope should be sub-scope of --- both parameters. We simplfy automatically if one tick scope is a +-- both parameters. We simplify automatically if one tick scope is a -- sub-scope of the other already. combineTickScopes :: CmmTickScope -> CmmTickScope -> CmmTickScope combineTickScopes s1 s2 diff --git a/compiler/cmm/CmmPipeline.hs b/compiler/cmm/CmmPipeline.hs index fbabea8f66..e7689a6bfe 100644 --- a/compiler/cmm/CmmPipeline.hs +++ b/compiler/cmm/CmmPipeline.hs @@ -297,7 +297,7 @@ cpsTop hsc_env proc = -- Sp = Sp + 16 -- ...y...y... -- --- But since we don't see any benefits from running sinking befroe stack +-- But since we don't see any benefits from running sinking before stack -- layout, this situation probably doesn't arise too often in practice. -- diff --git a/compiler/cmm/SMRep.hs b/compiler/cmm/SMRep.hs index 49137eff25..fe4ed58bfe 100644 --- a/compiler/cmm/SMRep.hs +++ b/compiler/cmm/SMRep.hs @@ -15,7 +15,7 @@ module SMRep ( StgHalfWord, fromStgHalfWord, toStgHalfWord, halfWordSize, halfWordSizeInBits, - -- * Closure repesentation + -- * Closure representation SMRep(..), -- CmmInfo sees the rep; no one else does IsStatic, ClosureTypeInfo(..), ArgDescr(..), Liveness, diff --git a/compiler/cmm/cmm-notes b/compiler/cmm/cmm-notes index 82d9673162..c1907f5908 100644 --- a/compiler/cmm/cmm-notes +++ b/compiler/cmm/cmm-notes @@ -1,185 +1,185 @@ -More notes (Aug 11)
-~~~~~~~~~~~~~~~~~~
-* CmmInfo.cmmToRawCmm expands info tables to their representations
- (needed for .cmm files as well as the code generators)
-
-* Why is FCode a lazy monad? That makes it inefficient.
- We want laziness to get code out one procedure at a time,
- but not at the instruction level.
- UPDATE (31/5/2016): FCode is strict since 09afcc9b.
-
-Things we did
- * Remove CmmCvt.graphToZgraph (Conversion from old to new Cmm reps)
- * Remove HscMain.optionallyConvertAndOrCPS (converted old Cmm to
- new, ran pipeline, and converted back)
- * Remove CmmDecl. Put its types in Cmm. Import Cmm into OldCmm
- so it can get those types.
-
-
-More notes (June 11)
-~~~~~~~~~~~~~~~~~~~~
-
-* In CmmContFlowOpts.branchChainElim, can a single block be the
- successor of two calls?
-
-* Check in ClosureInfo:
- -- NB: Results here should line up with the results of SMRep.rtsClosureType
-
-More notes (May 11)
-~~~~~~~~~~~~~~~~~~~
-In CmmNode, consider spliting CmmCall into two: call and jump
-
-Notes on new codegen (Aug 10)
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-Things to do:
- - Proc points pass all arguments on the stack, adding more code and
- slowing down things a lot. We either need to fix this or even better
- would be to get rid of proc points.
-
- - Sort out Label, LabelMap, LabelSet versus BlockId, BlockEnv, BlockSet
- dichotomy. Mostly this means global replace, but we also need to make
- Label an instance of Outputable (probably in the Outputable module).
-
- EZY: We should use Label, since that's the terminology Hoopl uses.
-
- - AsmCodeGen has a generic Cmm optimiser; move this into new pipeline
- EZY (2011-04-16): The mini-inliner has been generalized and ported,
- but the constant folding and other optimizations need to still be
- ported.
-
- - AsmCodeGen has post-native-cg branch eliminator (shortCutBranches);
- we ultimately want to share this with the Cmm branch eliminator.
-
- - At the moment, references to global registers like Hp are "lowered"
- late (in CgUtils.fixStgRegisters). We should do this early, in the
- new native codegen, much in the way that we lower calling conventions.
- Might need to be a bit sophisticated about aliasing.
-
- - Move to new Cmm rep:
- * Make native CG consume New Cmm;
- * Convert Old Cmm->New Cmm to keep old path alive
- * Produce New Cmm when reading in .cmm files
-
- - Top-level SRT threading is a bit ugly
-
- - See "CAFs" below; we want to totally refactor the way SRTs are calculated
-
- - Garbage-collect https://gitlab.haskell.org/ghc/ghc/wikis/commentary/compiler/cps
- moving good stuff into
- https://gitlab.haskell.org/ghc/ghc/wikis/commentary/compiler/new-code-gen-pipeline
-
- - Currently AsmCodeGen top level calls AsmCodeGen.cmmToCmm, which is a small
- C-- optimiser. It has quite a lot of boilerplate folding code in AsmCodeGen
- (cmmBlockConFold, cmmStmtConFold, cmmExprConFold), before calling out to
- CmmOpt. ToDo: see what optimisations are being done; and do them before
- AsmCodeGen.
-
- - If we stick CAF and stack liveness info on a LastCall node (not LastRet/Jump)
- then all CAF and stack liveness stuff be completed before we split
- into separate C procedures.
-
- Short term:
- compute and attach liveness into LastCall
- right at end, split, cvt to old rep
- [must split before cvt, because old rep is not expressive enough]
-
- Longer term:
- when old rep disappears,
- move the whole splitting game into the C back end *only*
- (guided by the procpoint set)
-
-----------------------------------------------------
- Proc-points
-----------------------------------------------------
-
-Consider this program, which has a diamond control flow,
-with a call on one branch
- fn(p,x) {
- h()
- if b then { ... f(x) ...; q=5; goto J }
- else { ...; q=7; goto J }
- J: ..p...q...
- }
-then the join point J is a "proc-point". So, is 'p' passed to J
-as a parameter? Or, if 'p' was saved on the stack anyway, perhaps
-to keep it alive across the call to h(), maybe 'p' gets communicated
-to J that way. This is an awkward choice. (We think that we currently
-never pass variables to join points via arguments.)
-
-Furthermore, there is *no way* to pass q to J in a register (other
-than a parameter register).
-
-What we want is to do register allocation across the whole caboodle.
-Then we could drop all the code that deals with the above awkward
-decisions about spilling variables across proc-points.
-
-Note that J doesn't need an info table.
-
-What we really want is for each LastCall (not LastJump/Ret)
-to have an info table. Note that ProcPoints that are not successors
-of calls don't need an info table.
-
-Figuring out proc-points
-~~~~~~~~~~~~~~~~~~~~~~~~
-Proc-points are identified by
-CmmProcPoint.minimalProcPointSet/extendPPSet Although there isn't
-that much code, JD thinks that it could be done much more nicely using
-a dominator analysis, using the Dataflow Engine.
-
-----------------------------------------------------
- CAFs
-----------------------------------------------------
-
-* The code for a procedure f may refer to either the *closure*
- or the *entry point* of another top-level procedure g.
- If f is live, then so is g. f's SRT must include g's closure.
-
-* The CLabel for the entry-point/closure reveals whether g is
- a CAF (or refers to CAFs). See the IdLabel constructor of CLabel.
-
-* The CAF-ness of the original top-level definitions is figured out
- (by TidyPgm) before we generate C--. This CafInfo is only set for
- top-level Ids; nested bindings stay with MayHaveCafRefs.
-
-* Currently an SRT contains (only) pointers to (top-level) closures.
-
-* Consider this Core code
- f = \x -> let g = \y -> ...x...y...h1...
- in ...h2...g...
- and suppose that h1, h2 have IdInfo of MayHaveCafRefs.
- Therefore, so will f, But g will not (since it's nested).
-
- This generates C-- roughly like this:
- f_closure: .word f_entry
- f_entry() [info-tbl-for-f] { ...jump g_entry...jump h2... }
- g_entry() [info-tbl-for-g] { ...jump h1... }
-
- Note that there is no top-level closure for g (only an info table).
- This fact (whether or not there is a top-level closure) is recorded
- in the InfoTable attached to the CmmProc for f, g
- INVARIANT:
- Any out-of-Group references to an IdLabel goes to
- a Proc whose InfoTable says "I have a top-level closure".
- Equivalently:
- A CmmProc whose InfoTable says "I do not have a top-level
- closure" is referred to only from its own Group.
-
-* So: info-tbl-for-f must have an SRT that keeps h1,h2 alive
- info-tbl-for-g must have an SRT that keeps h1 (only) alive
-
- But if we just look for the free CAF refs, we get:
- f h2 (only)
- g h1
-
- So we need to do a transitive closure thing to flesh out
- f's keep-alive refs to include h1.
-
-* The SRT info is the C_SRT field of Cmm.ClosureTypeInfo in a
- CmmInfoTable attached to each CmmProc. CmmPipeline.toTops actually does
- the attaching, right at the end of the pipeline. The C_SRT part
- gives offsets within a single, shared table of closure pointers.
-
-* DECIDED: we can generate SRTs based on the final Cmm program
- without knowledge of how it is generated.
-
+More notes (Aug 11) +~~~~~~~~~~~~~~~~~~ +* CmmInfo.cmmToRawCmm expands info tables to their representations + (needed for .cmm files as well as the code generators) + +* Why is FCode a lazy monad? That makes it inefficient. + We want laziness to get code out one procedure at a time, + but not at the instruction level. + UPDATE (31/5/2016): FCode is strict since 09afcc9b. + +Things we did + * Remove CmmCvt.graphToZgraph (Conversion from old to new Cmm reps) + * Remove HscMain.optionallyConvertAndOrCPS (converted old Cmm to + new, ran pipeline, and converted back) + * Remove CmmDecl. Put its types in Cmm. Import Cmm into OldCmm + so it can get those types. + + +More notes (June 11) +~~~~~~~~~~~~~~~~~~~~ + +* In CmmContFlowOpts.branchChainElim, can a single block be the + successor of two calls? + +* Check in ClosureInfo: + -- NB: Results here should line up with the results of SMRep.rtsClosureType + +More notes (May 11) +~~~~~~~~~~~~~~~~~~~ +In CmmNode, consider splitting CmmCall into two: call and jump + +Notes on new codegen (Aug 10) +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +Things to do: + - Proc points pass all arguments on the stack, adding more code and + slowing down things a lot. We either need to fix this or even better + would be to get rid of proc points. + + - Sort out Label, LabelMap, LabelSet versus BlockId, BlockEnv, BlockSet + dichotomy. Mostly this means global replace, but we also need to make + Label an instance of Outputable (probably in the Outputable module). + + EZY: We should use Label, since that's the terminology Hoopl uses. + + - AsmCodeGen has a generic Cmm optimiser; move this into new pipeline + EZY (2011-04-16): The mini-inliner has been generalized and ported, + but the constant folding and other optimizations need to still be + ported. + + - AsmCodeGen has post-native-cg branch eliminator (shortCutBranches); + we ultimately want to share this with the Cmm branch eliminator. + + - At the moment, references to global registers like Hp are "lowered" + late (in CgUtils.fixStgRegisters). We should do this early, in the + new native codegen, much in the way that we lower calling conventions. + Might need to be a bit sophisticated about aliasing. + + - Move to new Cmm rep: + * Make native CG consume New Cmm; + * Convert Old Cmm->New Cmm to keep old path alive + * Produce New Cmm when reading in .cmm files + + - Top-level SRT threading is a bit ugly + + - See "CAFs" below; we want to totally refactor the way SRTs are calculated + + - Garbage-collect https://gitlab.haskell.org/ghc/ghc/wikis/commentary/compiler/cps + moving good stuff into + https://gitlab.haskell.org/ghc/ghc/wikis/commentary/compiler/new-code-gen-pipeline + + - Currently AsmCodeGen top level calls AsmCodeGen.cmmToCmm, which is a small + C-- optimiser. It has quite a lot of boilerplate folding code in AsmCodeGen + (cmmBlockConFold, cmmStmtConFold, cmmExprConFold), before calling out to + CmmOpt. ToDo: see what optimisations are being done; and do them before + AsmCodeGen. + + - If we stick CAF and stack liveness info on a LastCall node (not LastRet/Jump) + then all CAF and stack liveness stuff be completed before we split + into separate C procedures. + + Short term: + compute and attach liveness into LastCall + right at end, split, cvt to old rep + [must split before cvt, because old rep is not expressive enough] + + Longer term: + when old rep disappears, + move the whole splitting game into the C back end *only* + (guided by the procpoint set) + +---------------------------------------------------- + Proc-points +---------------------------------------------------- + +Consider this program, which has a diamond control flow, +with a call on one branch + fn(p,x) { + h() + if b then { ... f(x) ...; q=5; goto J } + else { ...; q=7; goto J } + J: ..p...q... + } +then the join point J is a "proc-point". So, is 'p' passed to J +as a parameter? Or, if 'p' was saved on the stack anyway, perhaps +to keep it alive across the call to h(), maybe 'p' gets communicated +to J that way. This is an awkward choice. (We think that we currently +never pass variables to join points via arguments.) + +Furthermore, there is *no way* to pass q to J in a register (other +than a parameter register). + +What we want is to do register allocation across the whole caboodle. +Then we could drop all the code that deals with the above awkward +decisions about spilling variables across proc-points. + +Note that J doesn't need an info table. + +What we really want is for each LastCall (not LastJump/Ret) +to have an info table. Note that ProcPoints that are not successors +of calls don't need an info table. + +Figuring out proc-points +~~~~~~~~~~~~~~~~~~~~~~~~ +Proc-points are identified by +CmmProcPoint.minimalProcPointSet/extendPPSet Although there isn't +that much code, JD thinks that it could be done much more nicely using +a dominator analysis, using the Dataflow Engine. + +---------------------------------------------------- + CAFs +---------------------------------------------------- + +* The code for a procedure f may refer to either the *closure* + or the *entry point* of another top-level procedure g. + If f is live, then so is g. f's SRT must include g's closure. + +* The CLabel for the entry-point/closure reveals whether g is + a CAF (or refers to CAFs). See the IdLabel constructor of CLabel. + +* The CAF-ness of the original top-level definitions is figured out + (by TidyPgm) before we generate C--. This CafInfo is only set for + top-level Ids; nested bindings stay with MayHaveCafRefs. + +* Currently an SRT contains (only) pointers to (top-level) closures. + +* Consider this Core code + f = \x -> let g = \y -> ...x...y...h1... + in ...h2...g... + and suppose that h1, h2 have IdInfo of MayHaveCafRefs. + Therefore, so will f, But g will not (since it's nested). + + This generates C-- roughly like this: + f_closure: .word f_entry + f_entry() [info-tbl-for-f] { ...jump g_entry...jump h2... } + g_entry() [info-tbl-for-g] { ...jump h1... } + + Note that there is no top-level closure for g (only an info table). + This fact (whether or not there is a top-level closure) is recorded + in the InfoTable attached to the CmmProc for f, g + INVARIANT: + Any out-of-Group references to an IdLabel goes to + a Proc whose InfoTable says "I have a top-level closure". + Equivalently: + A CmmProc whose InfoTable says "I do not have a top-level + closure" is referred to only from its own Group. + +* So: info-tbl-for-f must have an SRT that keeps h1,h2 alive + info-tbl-for-g must have an SRT that keeps h1 (only) alive + + But if we just look for the free CAF refs, we get: + f h2 (only) + g h1 + + So we need to do a transitive closure thing to flesh out + f's keep-alive refs to include h1. + +* The SRT info is the C_SRT field of Cmm.ClosureTypeInfo in a + CmmInfoTable attached to each CmmProc. CmmPipeline.toTops actually does + the attaching, right at the end of the pipeline. The C_SRT part + gives offsets within a single, shared table of closure pointers. + +* DECIDED: we can generate SRTs based on the final Cmm program + without knowledge of how it is generated. + diff --git a/compiler/coreSyn/CoreFVs.hs b/compiler/coreSyn/CoreFVs.hs index fef3915c51..82b6805af5 100644 --- a/compiler/coreSyn/CoreFVs.hs +++ b/compiler/coreSyn/CoreFVs.hs @@ -496,7 +496,7 @@ ruleLhsFreeIds = fvVarSet . ruleLhsFVIds ruleLhsFreeIdsList :: CoreRule -> [Var] -- ^ This finds all locally-defined free Ids on the left hand side of a rule --- and returns them as a determinisitcally ordered list +-- and returns them as a deterministically ordered list ruleLhsFreeIdsList = fvVarList . ruleLhsFVIds ruleLhsFVIds :: CoreRule -> FV diff --git a/compiler/coreSyn/CoreLint.hs b/compiler/coreSyn/CoreLint.hs index 4aeb2cf698..7c4137e9b5 100644 --- a/compiler/coreSyn/CoreLint.hs +++ b/compiler/coreSyn/CoreLint.hs @@ -166,7 +166,7 @@ That is, use a type let. See Note [Type let] in CoreSyn. However, when linting <body> we need to remember that a=Int, else we might reject a correct program. So we carry a type substitution (in this example -[a -> Int]) and apply this substitution before comparing types. The functin +[a -> Int]) and apply this substitution before comparing types. The function lintInTy :: Type -> LintM (Type, Kind) returns a substituted type. diff --git a/compiler/coreSyn/CoreSubst.hs b/compiler/coreSyn/CoreSubst.hs index afb8946426..904e9eec04 100644 --- a/compiler/coreSyn/CoreSubst.hs +++ b/compiler/coreSyn/CoreSubst.hs @@ -745,7 +745,7 @@ Breakpoints can't handle free variables with unlifted types anyway. {- Note [Worker inlining] ~~~~~~~~~~~~~~~~~~~~~~ -A worker can get sustituted away entirely. +A worker can get substituted away entirely. - it might be trivial - it might simply be very small We do not treat an InlWrapper as an 'occurrence' in the occurrence diff --git a/compiler/coreSyn/CoreTidy.hs b/compiler/coreSyn/CoreTidy.hs index 3c924663f5..7642606813 100644 --- a/compiler/coreSyn/CoreTidy.hs +++ b/compiler/coreSyn/CoreTidy.hs @@ -196,7 +196,7 @@ tidyLetBndr rec_tidy_env env@(tidy_env, var_env) id -- Don't attempt to recompute arity here; this is just tidying! -- Trying to do so led to #17294 -- - -- Set inline-prag info so that we preseve it across + -- Set inline-prag info so that we preserve it across -- separate compilation boundaries old_info = idInfo id new_info = vanillaIdInfo diff --git a/compiler/coreSyn/MkCore.hs b/compiler/coreSyn/MkCore.hs index 73f371edd0..7e5bbe548c 100644 --- a/compiler/coreSyn/MkCore.hs +++ b/compiler/coreSyn/MkCore.hs @@ -886,7 +886,7 @@ After doing case-of-known-constructor, and expanding $WMkT we get Yikes! That bogusly appears to evaluate the absentError! This is extremely tiresome. Another way to think of this is that, in -Core, it is an invariant that a strict data contructor, like MkT, must +Core, it is an invariant that a strict data constructor, like MkT, must be applied only to an argument in HNF. So (absentError "blah") had better be non-bottom. diff --git a/compiler/deSugar/DsListComp.hs b/compiler/deSugar/DsListComp.hs index 74fffacc73..35a71ce8e4 100644 --- a/compiler/deSugar/DsListComp.hs +++ b/compiler/deSugar/DsListComp.hs @@ -380,7 +380,7 @@ dfBindComp c_id n_id (pat, core_list1) quals = do b <- newSysLocalDs b_ty x <- newSysLocalDs x_ty - -- build rest of the comprehesion + -- build rest of the comprehension core_rest <- dfListComp c_id b quals -- build the pattern match diff --git a/compiler/deSugar/MatchCon.hs b/compiler/deSugar/MatchCon.hs index 43d71acfdf..d1a0390da1 100644 --- a/compiler/deSugar/MatchCon.hs +++ b/compiler/deSugar/MatchCon.hs @@ -253,7 +253,7 @@ Now consider: In the first we must test y first; in the second we must test x first. So we must divide even the equations for a single constructor -T into sub-goups, based on whether they match the same field in the +T into sub-groups, based on whether they match the same field in the same order. That's what the (groupBy compatible_pats) grouping. All non-record patterns are "compatible" in this sense, because the diff --git a/compiler/ghci/ByteCodeInstr.hs b/compiler/ghci/ByteCodeInstr.hs index c386ece52a..b0db198037 100644 --- a/compiler/ghci/ByteCodeInstr.hs +++ b/compiler/ghci/ByteCodeInstr.hs @@ -68,7 +68,7 @@ data BCInstr | PUSH32 !Word16 -- Push the specifiec local as a 8, 16, 32 bit value onto the stack, but the - -- value will take the whole word on the stack (i.e., the stack will gorw by + -- value will take the whole word on the stack (i.e., the stack will grow by -- a word) -- This is useful when extracting a packed constructor field for further use. -- Currently we expect all values on the stack to take full words, except for diff --git a/compiler/hieFile/HieBin.hs b/compiler/hieFile/HieBin.hs index 0a5d60df92..866c0f007f 100644 --- a/compiler/hieFile/HieBin.hs +++ b/compiler/hieFile/HieBin.hs @@ -48,7 +48,7 @@ instance Ord HieName where compare (ExternalName a b c) (ExternalName d e f) = compare (a,b,c) (d,e,f) compare (LocalName a b) (LocalName c d) = compare (a,b) (c,d) compare (KnownKeyName a) (KnownKeyName b) = nonDetCmpUnique a b - -- Not actually non determinstic as it is a KnownKey + -- Not actually non deterministic as it is a KnownKey compare ExternalName{} _ = LT compare LocalName{} ExternalName{} = GT compare LocalName{} _ = LT diff --git a/compiler/iface/IfaceType.hs b/compiler/iface/IfaceType.hs index d649be701b..7a8c617bb7 100644 --- a/compiler/iface/IfaceType.hs +++ b/compiler/iface/IfaceType.hs @@ -1320,7 +1320,7 @@ pprTyTcApp' ctxt_prec tc tys dflags style | otherwise = getPprDebug $ \dbg -> if | not dbg && tc `ifaceTyConHasKey` errorMessageTypeErrorFamKey - -- Suppress detail unles you _really_ want to see + -- Suppress detail unless you _really_ want to see -> text "(TypeError ...)" | Just doc <- ppr_equality ctxt_prec tc (appArgsIfaceTypes tys) diff --git a/compiler/iface/TcIface.hs b/compiler/iface/TcIface.hs index 818745775a..34cf2c247e 100644 --- a/compiler/iface/TcIface.hs +++ b/compiler/iface/TcIface.hs @@ -495,7 +495,7 @@ tcHiBootIface hsc_src mod -- In --make and interactive mode, if this module has an hs-boot file -- we'll have compiled it already, and it'll be in the HPT -- - -- We check wheher the interface is a *boot* interface. + -- We check whether the interface is a *boot* interface. -- It can happen (when using GHC from Visual Studio) that we -- compile a module in TypecheckOnly mode, with a stable, -- fully-populated HPT. In that case the boot interface isn't there diff --git a/compiler/llvmGen/LlvmCodeGen/Base.hs b/compiler/llvmGen/LlvmCodeGen/Base.hs index f43c3dcf75..9ddb23aade 100644 --- a/compiler/llvmGen/LlvmCodeGen/Base.hs +++ b/compiler/llvmGen/LlvmCodeGen/Base.hs @@ -582,7 +582,7 @@ aliasify (LMGlobal var val) = do -- point of definition instead of the point of usage, as was previously -- done. See #9142 for details. -- --- Finally, case (1) is trival. As we already have a definition for +-- Finally, case (1) is trivial. As we already have a definition for -- and therefore know the type of the referenced symbol, we can do -- away with casting the alias to the desired type in @getSymbolPtr@ -- and instead just emit a reference to the definition symbol directly. diff --git a/compiler/main/Ar.hs b/compiler/main/Ar.hs index 73292d0ae3..1a1862a6fe 100644 --- a/compiler/main/Ar.hs +++ b/compiler/main/Ar.hs @@ -13,7 +13,7 @@ the same name.) As Archives are rather simple structurally, we can just build the archives with Haskell directly and use ranlib on the final result to get the symbol index. This should allow us to work around with the differences/abailability -of libtool across differet platforms. +of libtool across different platforms. -} module Ar (ArchiveEntry(..) diff --git a/compiler/main/DriverMkDepend.hs b/compiler/main/DriverMkDepend.hs index 6368d8c785..04b438c018 100644 --- a/compiler/main/DriverMkDepend.hs +++ b/compiler/main/DriverMkDepend.hs @@ -383,7 +383,7 @@ pprCycle summaries = pp_group (CyclicSCC summaries) pp_group (CyclicSCC mss) = ASSERT( not (null boot_only) ) -- The boot-only list must be non-empty, else there would - -- be an infinite chain of non-boot imoprts, and we've + -- be an infinite chain of non-boot imports, and we've -- already checked for that in processModDeps pp_ms loop_breaker $$ vcat (map pp_group groups) where diff --git a/compiler/main/GHC.hs b/compiler/main/GHC.hs index def7065ab6..140c8904e2 100644 --- a/compiler/main/GHC.hs +++ b/compiler/main/GHC.hs @@ -638,7 +638,7 @@ setProgramDynFlags_ invalidate_needed dflags = do -- that the next downsweep will think that all the files have changed -- and preprocess them again. This won't necessarily cause everything -- to be recompiled, because by the time we check whether we need to --- recopmile a module, we'll have re-summarised the module and have a +-- recompile a module, we'll have re-summarised the module and have a -- correct ModSummary. -- invalidateModSummaryCache :: GhcMonad m => m () diff --git a/compiler/main/HscTypes.hs b/compiler/main/HscTypes.hs index d1e0603088..4a848864f8 100644 --- a/compiler/main/HscTypes.hs +++ b/compiler/main/HscTypes.hs @@ -1651,7 +1651,7 @@ It's exactly the same for type-family instances. See #7102 data InteractiveContext = InteractiveContext { ic_dflags :: DynFlags, - -- ^ The 'DynFlags' used to evaluate interative expressions + -- ^ The 'DynFlags' used to evaluate interactive expressions -- and statements. ic_mod_index :: Int, diff --git a/compiler/main/PprTyThing.hs b/compiler/main/PprTyThing.hs index 4e49b6c661..b918943c8e 100644 --- a/compiler/main/PprTyThing.hs +++ b/compiler/main/PprTyThing.hs @@ -38,7 +38,7 @@ import Outputable {- Note [Pretty printing via IfaceSyn] ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -Our general plan for prett-printing +Our general plan for pretty-printing - Types - TyCons - Classes diff --git a/compiler/nativeGen/BlockLayout.hs b/compiler/nativeGen/BlockLayout.hs index ba15e0063f..9b5f2eda8f 100644 --- a/compiler/nativeGen/BlockLayout.hs +++ b/compiler/nativeGen/BlockLayout.hs @@ -374,7 +374,7 @@ combineNeighbourhood :: [CfgEdge] -- ^ Edges to consider -- were used to fuse chains and as such no longer need to be -- considered. combineNeighbourhood edges chains - = -- pprTraceIt "Neigbours" $ + = -- pprTraceIt "Neighbours" $ -- pprTrace "combineNeighbours" (ppr edges) $ applyEdges edges endFrontier startFrontier (Set.empty) where diff --git a/compiler/nativeGen/NCGMonad.hs b/compiler/nativeGen/NCGMonad.hs index 71503aa653..e1bb927d0b 100644 --- a/compiler/nativeGen/NCGMonad.hs +++ b/compiler/nativeGen/NCGMonad.hs @@ -226,7 +226,7 @@ addNodeBetweenNat from between to addWeightEdge between old weight . delEdge from old $ m | otherwise - = pprPanic "Faild to update cfg: Untracked edge" (ppr (from,to)) + = pprPanic "Failed to update cfg: Untracked edge" (ppr (from,to)) -- | Place `succ` after `block` and change any edges diff --git a/compiler/nativeGen/PIC.hs b/compiler/nativeGen/PIC.hs index a38f3fa18f..760ba7925d 100644 --- a/compiler/nativeGen/PIC.hs +++ b/compiler/nativeGen/PIC.hs @@ -217,7 +217,7 @@ howToAccessLabel -- Windows -- In Windows speak, a "module" is a set of objects linked into the --- same Portable Exectuable (PE) file. (both .exe and .dll files are PEs). +-- same Portable Executable (PE) file. (both .exe and .dll files are PEs). -- -- If we're compiling a multi-module program then symbols from other modules -- are accessed by a symbol pointer named __imp_SYMBOL. At runtime we have the diff --git a/compiler/nativeGen/PPC/CodeGen.hs b/compiler/nativeGen/PPC/CodeGen.hs index 05883d0e5a..e669630956 100644 --- a/compiler/nativeGen/PPC/CodeGen.hs +++ b/compiler/nativeGen/PPC/CodeGen.hs @@ -425,7 +425,7 @@ getRegister' dflags (CmmReg reg) getRegister' dflags tree@(CmmRegOff _ _) = getRegister' dflags (mangleIndexTree dflags tree) - -- for 32-bit architectuers, support some 64 -> 32 bit conversions: + -- for 32-bit architectures, support some 64 -> 32 bit conversions: -- TO_W_(x), TO_W_(x >> 32) getRegister' dflags (CmmMachOp (MO_UU_Conv W64 W32) diff --git a/compiler/nativeGen/RegAlloc/Graph/Main.hs b/compiler/nativeGen/RegAlloc/Graph/Main.hs index e756068ca1..1171689e66 100644 --- a/compiler/nativeGen/RegAlloc/Graph/Main.hs +++ b/compiler/nativeGen/RegAlloc/Graph/Main.hs @@ -83,7 +83,7 @@ regAlloc dflags regsFree slotsFree slotsCount code cfg -- | Perform solver iterations for the graph coloring allocator. -- --- We extract a register confict graph from the provided cmm code, +-- We extract a register conflict graph from the provided cmm code, -- and try to colour it. If that works then we use the solution rewrite -- the code with real hregs. If coloring doesn't work we add spill code -- and try to colour it again. After `maxSpinCount` iterations we give up. diff --git a/compiler/nativeGen/RegAlloc/Graph/SpillCost.hs b/compiler/nativeGen/RegAlloc/Graph/SpillCost.hs index 4be25a71ba..42de5503ba 100644 --- a/compiler/nativeGen/RegAlloc/Graph/SpillCost.hs +++ b/compiler/nativeGen/RegAlloc/Graph/SpillCost.hs @@ -38,7 +38,7 @@ import Data.Maybe import Control.Monad (join) --- | Records the expected cost to spill some regster. +-- | Records the expected cost to spill some register. type SpillCostRecord = ( VirtualReg -- register name , Int -- number of writes to this reg diff --git a/compiler/nativeGen/RegAlloc/Graph/TrivColorable.hs b/compiler/nativeGen/RegAlloc/Graph/TrivColorable.hs index 773db33293..cc2ad7d594 100644 --- a/compiler/nativeGen/RegAlloc/Graph/TrivColorable.hs +++ b/compiler/nativeGen/RegAlloc/Graph/TrivColorable.hs @@ -26,7 +26,7 @@ import Panic -- This gets hammered by scanGraph during register allocation, -- so needs to be fairly efficient. -- --- NOTE: This only works for arcitectures with just RcInteger and RcDouble +-- NOTE: This only works for architectures with just RcInteger and RcDouble -- (which are disjoint) ie. x86, x86_64 and ppc -- -- The number of allocatable regs is hard coded in here so we can do diff --git a/compiler/parser/RdrHsSyn.hs b/compiler/parser/RdrHsSyn.hs index 75ce613353..b2e8806caa 100644 --- a/compiler/parser/RdrHsSyn.hs +++ b/compiler/parser/RdrHsSyn.hs @@ -1042,7 +1042,7 @@ checkImportDecl mPre mPost = do importQualifiedPostEnabled <- getBit ImportQualifiedPostBit - -- Error if 'qualified' found in postpostive position and + -- Error if 'qualified' found in postpositive position and -- 'ImportQualifiedPost' is not in effect. whenJust mPost $ \post -> when (not importQualifiedPostEnabled) $ diff --git a/compiler/prelude/TysPrim.hs b/compiler/prelude/TysPrim.hs index a023c430fe..a25540290a 100644 --- a/compiler/prelude/TysPrim.hs +++ b/compiler/prelude/TysPrim.hs @@ -442,7 +442,7 @@ So for example: We abbreviate '*' specially: type * = TYPE 'LiftedRep -The 'rr' parameter tells us how the value is represented at runime. +The 'rr' parameter tells us how the value is represented at runtime. Generally speaking, you can't be polymorphic in 'rr'. E.g f :: forall (rr:RuntimeRep) (a:TYPE rr). a -> [a] diff --git a/compiler/simplCore/CoreMonad.hs b/compiler/simplCore/CoreMonad.hs index 04898921de..9832445b09 100644 --- a/compiler/simplCore/CoreMonad.hs +++ b/compiler/simplCore/CoreMonad.hs @@ -415,7 +415,7 @@ pprTickCounts :: Map Tick Int -> SDoc pprTickCounts counts = vcat (map pprTickGroup groups) where - groups :: [[(Tick,Int)]] -- Each group shares a comon tag + groups :: [[(Tick,Int)]] -- Each group shares a common tag -- toList returns common tags adjacent groups = groupBy same_tag (Map.toList counts) same_tag (tick1,_) (tick2,_) = tickToTag tick1 == tickToTag tick2 diff --git a/compiler/simplCore/FloatOut.hs b/compiler/simplCore/FloatOut.hs index c0110fa1d9..a49d043e8f 100644 --- a/compiler/simplCore/FloatOut.hs +++ b/compiler/simplCore/FloatOut.hs @@ -529,7 +529,7 @@ from the body of the let that depend on the staying-put bindings. We used instead to do the partitionByMajorLevel on the RHS of an '=', in floatRhs. But that was quite tiresome. We needed to test for -values or trival rhss, because (in particular) we don't want to insert +values or trivial rhss, because (in particular) we don't want to insert new bindings between the "=" and the "\". E.g. f = \x -> let <bind> in <body> We do not want diff --git a/compiler/simplCore/LiberateCase.hs b/compiler/simplCore/LiberateCase.hs index b484de3bc3..9cd21e0e18 100644 --- a/compiler/simplCore/LiberateCase.hs +++ b/compiler/simplCore/LiberateCase.hs @@ -164,7 +164,7 @@ libCaseBind env (Rec pairs) {- Note [Not bottoming Ids] ~~~~~~~~~~~~~~~~~~~~~~~~~~~ Do not specialise error-functions (this is unusual, but I once saw it, -(acually in Data.Typable.Internal) +(actually in Data.Typable.Internal) Note [Only functions!] ~~~~~~~~~~~~~~~~~~~~~~ diff --git a/compiler/simplCore/SimplCore.hs b/compiler/simplCore/SimplCore.hs index 19465082dc..1d55c17d36 100644 --- a/compiler/simplCore/SimplCore.hs +++ b/compiler/simplCore/SimplCore.hs @@ -881,7 +881,7 @@ Hence,there's a possibility of leaving unchanged something like this: By the time we've thrown away the types in STG land this could be eliminated. But I don't think it's very common and it's dangerous to do this fiddling in STG land -because we might elminate a binding that's mentioned in the +because we might eliminate a binding that's mentioned in the unfolding for something. Note [Indirection zapping and ticks] diff --git a/compiler/simplCore/SimplEnv.hs b/compiler/simplCore/SimplEnv.hs index a17d6b4bda..0c440efc69 100644 --- a/compiler/simplCore/SimplEnv.hs +++ b/compiler/simplCore/SimplEnv.hs @@ -372,7 +372,7 @@ where the let shadows the lambda. Really this means something like - Then that continuation gets pushed under the let - Finally we simplify 'arg'. We want - - the static, lexical environment bindig x :-> x1 + - the static, lexical environment binding x :-> x1 - the in-scopeset from "here", under the 'let' which includes both x1 and x2 diff --git a/compiler/specialise/Specialise.hs b/compiler/specialise/Specialise.hs index 3eabb191d7..642071129e 100644 --- a/compiler/specialise/Specialise.hs +++ b/compiler/specialise/Specialise.hs @@ -199,7 +199,7 @@ the two instances of +.sel weren't originally at the same type. Further notes on (b) * There are quite a few variations here. For example, the defn of - +.sel could be floated ouside the \y, to attempt to gain laziness. + +.sel could be floated outside the \y, to attempt to gain laziness. It certainly mustn't be floated outside the \d because the d has to be in scope too. diff --git a/compiler/stranal/WwLib.hs b/compiler/stranal/WwLib.hs index 6feb1ff065..d235d3c649 100644 --- a/compiler/stranal/WwLib.hs +++ b/compiler/stranal/WwLib.hs @@ -209,7 +209,7 @@ Note [Always do CPR w/w] ~~~~~~~~~~~~~~~~~~~~~~~~ At one time we refrained from doing CPR w/w for thunks, on the grounds that we might duplicate work. But that is already handled by the demand analyser, -which doesn't give the CPR proprety if w/w might waste work: see +which doesn't give the CPR property if w/w might waste work: see Note [CPR for thunks] in DmdAnal. And if something *has* been given the CPR property and we don't w/w, it's diff --git a/compiler/typecheck/FamInst.hs b/compiler/typecheck/FamInst.hs index 36c613c186..ee9a148eaa 100644 --- a/compiler/typecheck/FamInst.hs +++ b/compiler/typecheck/FamInst.hs @@ -1042,7 +1042,7 @@ reportConflictInstErr fam_inst (match1 : _) , let ax = famInstAxiom fi ]) where getSpan = getSrcLoc . famInstAxiom - -- The sortWith just arranges that instances are dislayed in order + -- The sortWith just arranges that instances are displayed in order -- of source location, which reduced wobbling in error messages, -- and is better for users diff --git a/compiler/typecheck/TcExpr.hs b/compiler/typecheck/TcExpr.hs index 5560b219ba..bfbb4d260c 100644 --- a/compiler/typecheck/TcExpr.hs +++ b/compiler/typecheck/TcExpr.hs @@ -1339,7 +1339,7 @@ users complain bitterly (#13834, #17150.) The right error is the CHoleCan, which reports 'wurble' as out of scope, and tries to give its type. -Fortunately in tcArgs we still have acces to the function, so +Fortunately in tcArgs we still have access to the function, so we can check if it is a HsUnboundVar. If so, we simply fail immediately. We've already inferred the type of the function, so we'll /already/ have emitted a CHoleCan constraint; failing diff --git a/compiler/typecheck/TcOrigin.hs b/compiler/typecheck/TcOrigin.hs index e1cf64f731..c3af30e615 100644 --- a/compiler/typecheck/TcOrigin.hs +++ b/compiler/typecheck/TcOrigin.hs @@ -639,7 +639,7 @@ pprCtO IfOrigin = text "an if expression" pprCtO (LiteralOrigin lit) = hsep [text "the literal", quotes (ppr lit)] pprCtO (ArithSeqOrigin seq) = hsep [text "the arithmetic sequence", quotes (ppr seq)] pprCtO SectionOrigin = text "an operator section" -pprCtO AssocFamPatOrigin = text "the LHS of a famly instance" +pprCtO AssocFamPatOrigin = text "the LHS of a family instance" pprCtO TupleOrigin = text "a tuple" pprCtO NegateOrigin = text "a use of syntactic negation" pprCtO (ScOrigin n) = text "the superclasses of an instance declaration" diff --git a/compiler/typecheck/TcPatSyn.hs b/compiler/typecheck/TcPatSyn.hs index 1c39801f2f..1a6d3ea1e4 100644 --- a/compiler/typecheck/TcPatSyn.hs +++ b/compiler/typecheck/TcPatSyn.hs @@ -283,7 +283,7 @@ Similarly consider pattern Bam x y <- (MkS (x::a), MkS (y::a))) The pattern (Bam x y) binds two (Ord a) dictionaries, but we only -need one. Agian mkMimimalWithSCs removes the redundant one. +need one. Again mkMimimalWithSCs removes the redundant one. Note [Equality evidence in pattern synonyms] ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ diff --git a/compiler/typecheck/TcRules.hs b/compiler/typecheck/TcRules.hs index 192a82c56a..e63e670e03 100644 --- a/compiler/typecheck/TcRules.hs +++ b/compiler/typecheck/TcRules.hs @@ -108,7 +108,7 @@ tcRule (HsRule { rd_ext = ext -- RULE: forall v. fst (ss v) = fst v -- The type of the rhs of the rule is just a, but v::(a,(b,c)) -- - -- We also need to get the completely-uconstrained tyvars of + -- We also need to get the completely-unconstrained tyvars of -- the LHS, lest they otherwise get defaulted to Any; but we do that -- during zonking (see TcHsSyn.zonkRule) diff --git a/compiler/types/Coercion.hs b/compiler/types/Coercion.hs index b338bfbf9e..16db7c5f6c 100644 --- a/compiler/types/Coercion.hs +++ b/compiler/types/Coercion.hs @@ -1943,7 +1943,7 @@ liftCoSubstTyVar (LC subst env) r v callback: We want 'liftCoSubstVarBndrUsing' to be general enough to be reused in - FamInstEnv, therefore the input arg 'fun' returns a pair with polymophic type + FamInstEnv, therefore the input arg 'fun' returns a pair with polymorphic type in snd. However in 'liftCoSubstVarBndr', we don't need the snd, so we use unit and ignore the fourth component of the return value. diff --git a/compiler/types/OptCoercion.hs b/compiler/types/OptCoercion.hs index 55771f6dd0..b8f9f6ce8f 100644 --- a/compiler/types/OptCoercion.hs +++ b/compiler/types/OptCoercion.hs @@ -1166,7 +1166,7 @@ etaTyConAppCo_maybe tc co , tc1 == tc2 , isInjectiveTyCon tc r -- See Note [NthCo and newtypes] in TyCoRep , let n = length tys1 - , tys2 `lengthIs` n -- This can fail in an erroneous progam + , tys2 `lengthIs` n -- This can fail in an erroneous program -- E.g. T a ~# T a b -- #14607 = ASSERT( tc == tc1 ) diff --git a/compiler/types/TyCoFVs.hs b/compiler/types/TyCoFVs.hs index eefd68f145..10dc6453b0 100644 --- a/compiler/types/TyCoFVs.hs +++ b/compiler/types/TyCoFVs.hs @@ -84,7 +84,7 @@ so we profiled several versions, exploring different implementation strategies. This looks deceptively similar, but while FV internally builds a list- and set-generating function, the VarSet functions manipulate sets directly, and - the latter peforms a lot worse than the naive FV version. + the latter performs a lot worse than the naive FV version. 3. Accumulator-style VarSet version: this is what we use now. We do use VarSet as our data structure, but delegate the actual work to a new diff --git a/compiler/types/TyCoSubst.hs b/compiler/types/TyCoSubst.hs index db7563914f..7c1a811ae3 100644 --- a/compiler/types/TyCoSubst.hs +++ b/compiler/types/TyCoSubst.hs @@ -527,7 +527,7 @@ hole will remain. Then, when we're checking x's definition, we skolemise x's type (in order to, e.g., bring the scoped type variable `a` into scope). This requires performing a substitution for the fresh skolem variables. -This subsitution needs to affect the kind of the coercion hole, too -- +This substitution needs to affect the kind of the coercion hole, too -- otherwise, the kind will have an out-of-scope variable in it. More problematically in practice (we won't actually notice the out-of-scope variable ever), skolems in the kind might have too high a level, triggering a failure to uphold the diff --git a/compiler/types/TyCoTidy.hs b/compiler/types/TyCoTidy.hs index 5c0825a6fa..f4639ca303 100644 --- a/compiler/types/TyCoTidy.hs +++ b/compiler/types/TyCoTidy.hs @@ -144,7 +144,7 @@ tidyType env (CoercionTy co) = CoercionTy $! (tidyCo env co) -- The following two functions differ from mkForAllTys and splitForAllTys in that --- they expect/preserve the ArgFlag argument. Thes belong to types/Type.hs, but +-- they expect/preserve the ArgFlag argument. These belong to types/Type.hs, but -- how should they be named? mkForAllTys' :: [(TyCoVar, ArgFlag)] -> Type -> Type mkForAllTys' tvvs ty = foldr strictMkForAllTy ty tvvs diff --git a/compiler/utils/Binary.hs b/compiler/utils/Binary.hs index 94a09288b5..f363976626 100644 --- a/compiler/utils/Binary.hs +++ b/compiler/utils/Binary.hs @@ -670,7 +670,7 @@ Consider a valie like `2724268014499746065`, some sort of hash actually generated by GHC. In the old scheme this was encoded as a list of 19 chars. This gave a size of 77 Bytes, one for the length of the list and 76 -since we encod chars as Word32 as well. +since we encode chars as Word32 as well. We can easily do better. The new plan is: diff --git a/compiler/utils/Digraph.hs b/compiler/utils/Digraph.hs index c205c45d8d..49ded1b23f 100644 --- a/compiler/utils/Digraph.hs +++ b/compiler/utils/Digraph.hs @@ -464,7 +464,7 @@ instance Outputable EdgeType where newtype Time = Time Int deriving (Eq,Ord,Num,Outputable) ---Allow for specialzation +--Allow for specialization {-# INLINEABLE classifyEdges #-} -- | Given a start vertex, a way to get successors from a node diff --git a/compiler/utils/FastString.hs b/compiler/utils/FastString.hs index 62a81aa10d..f11c4ebbb8 100644 --- a/compiler/utils/FastString.hs +++ b/compiler/utils/FastString.hs @@ -20,7 +20,7 @@ -- -- * Pointer and size of a Latin-1 encoded string. -- * Practically no operations. --- * Outputing them is fast. +-- * Outputting them is fast. -- * Generated by 'sLit'. -- * Turn into 'Outputable.SDoc' with 'Outputable.ptext' -- * Requires manual memory management. @@ -73,7 +73,7 @@ module FastString nilFS, isUnderscoreFS, - -- ** Outputing + -- ** Outputting hPutFS, -- ** Internal diff --git a/compiler/utils/GraphBase.hs b/compiler/utils/GraphBase.hs index b66599356e..a165b003ba 100644 --- a/compiler/utils/GraphBase.hs +++ b/compiler/utils/GraphBase.hs @@ -87,7 +87,7 @@ data Node k cls color -- | Colors that cannot be used by this node. , nodeExclusions :: UniqSet color - -- | Colors that this node would prefer to be, in decending order. + -- | Colors that this node would prefer to be, in descending order. , nodePreference :: [color] -- | Neighbors that this node would like to be colored the same as. diff --git a/compiler/utils/GraphColor.hs b/compiler/utils/GraphColor.hs index 4c1388e91d..82ec522357 100644 --- a/compiler/utils/GraphColor.hs +++ b/compiler/utils/GraphColor.hs @@ -76,7 +76,7 @@ colorGraph iterative spinCount colors triv spill graph0 -- We need to apply all the coalescences found by the scanner to the original -- graph before doing assignColors. -- - -- Because we've got the whole, non-pruned graph here we turn on aggressive coalecing + -- Because we've got the whole, non-pruned graph here we turn on aggressive coalescing -- to force all the (conservative) coalescences found during scanning. -- (graph_scan_coalesced, _) diff --git a/compiler/utils/GraphOps.hs b/compiler/utils/GraphOps.hs index 0a7981b0c8..cc8668ea45 100644 --- a/compiler/utils/GraphOps.hs +++ b/compiler/utils/GraphOps.hs @@ -233,7 +233,7 @@ addExclusions u getClass colors graph = foldr (addExclusion u getClass) graph colors --- | Add a coalescence edge to the graph, creating nodes if requried. +-- | Add a coalescence edge to the graph, creating nodes if required. -- It is considered adventageous to assign the same color to nodes in a coalesence. addCoalesce :: Uniquable k diff --git a/compiler/utils/Outputable.hs b/compiler/utils/Outputable.hs index b200bd79db..6717430a58 100644 --- a/compiler/utils/Outputable.hs +++ b/compiler/utils/Outputable.hs @@ -39,7 +39,7 @@ module Outputable ( coloured, keyword, - -- * Converting 'SDoc' into strings and outputing it + -- * Converting 'SDoc' into strings and outputting it printSDoc, printSDocLn, printForUser, printForUserPartWay, printForC, bufLeftRenderSDoc, pprCode, mkCodeStyle, |