Commit 70472bf2 authored by Gabor Greif's avatar Gabor Greif 💬

Spelling fixes in comments [ci skip]

parent e324e317
......@@ -910,7 +910,7 @@ instance Outputable OccInfo where
{-
************************************************************************
* *
Default method specfication
Default method specification
* *
************************************************************************
......
......@@ -1147,7 +1147,7 @@ instance Ord ImpItemSpec where
bestImport :: [ImportSpec] -> ImportSpec
-- Given a non-empty bunch of ImportSpecs, return the one that
-- imported the item most specficially (e.g. by name), using
-- imported the item most specifically (e.g. by name), using
-- textually-first as a tie breaker. This is used when reporting
-- redundant imports
bestImport iss
......
......@@ -801,7 +801,7 @@ chooseOrphanAnchor :: NameSet -> IsOrphan
-- Something (rule, instance) is relate to all the Names in this
-- list. Choose one of them to be an "anchor" for the orphan. We make
-- the choice deterministic to avoid gratuitious changes in the ABI
-- hash (Trac #4012). Specficially, use lexicographic comparison of
-- hash (Trac #4012). Specifically, use lexicographic comparison of
-- OccName rather than comparing Uniques
--
-- NB: 'minimum' use Ord, and (Ord OccName) works lexicographically
......
......@@ -1369,7 +1369,7 @@ However, watch out:
Note [Interaction of exprIsWorkFree and lone variables]
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The lone-variable test says "don't inline if a case expression
scrutines a lone variable whose unfolding is cheap". It's very
scrutinises a lone variable whose unfolding is cheap". It's very
important that, under these circumstances, exprIsConApp_maybe
can spot a constructor application. So, for example, we don't
consider
......
......@@ -256,7 +256,7 @@ hsExprToPmExpr e@(ExplicitList _elem_ty mb_ol elems)
hsExprToPmExpr (ExplicitPArr _elem_ty elems)
= PmExprCon (parrFakeCon (length elems)) (map lhsExprToPmExpr elems)
-- we want this but we would have to make evrything monadic :/
-- we want this but we would have to make everything monadic :/
-- ./compiler/deSugar/DsMonad.hs:397:dsLookupDataCon :: Name -> DsM DataCon
--
-- hsExprToPmExpr (RecordCon c _ binds) = do
......
......@@ -517,7 +517,7 @@ interface files for types mentioned in the arg types.
E.g.
data Foo.S = MkS Baz.T
Mabye we can get away without even loading the interface for Baz!
Maybe we can get away without even loading the interface for Baz!
This is not just a performance thing. Suppose we have
data Foo.S = MkS Baz.T
......
......@@ -151,7 +151,7 @@ data LlvmStatement
| Store LlvmVar LlvmVar
{- |
Mutliway branch
Multiway branch
* scrutinee: Variable or constant which must be of integer type that is
determines which arm is chosen.
* def: The default label if there is no match in target.
......
......@@ -11,7 +11,7 @@ import Outputable
-- following design:
-- * Metadata can be constructed in a few different ways (See below).
-- * After which it can either be attached to LLVM statements to pass along
-- extra information to the optimizer and code generator OR specificially named
-- extra information to the optimizer and code generator OR specifically named
-- metadata has an affect on the whole module (i.e., linking behaviour).
--
--
......
......@@ -1231,7 +1231,7 @@ get_op other = pprPanic "get_op" (ppr other)
-- Parser left-associates everything, but
-- derived instances may have correctly-associated things to
-- in the right operarand. So we just check that the right operand is OK
-- in the right operand. So we just check that the right operand is OK
right_op_ok :: Fixity -> HsExpr Name -> Bool
right_op_ok fix1 (OpApp _ _ fix2 _)
= not error_please && associate_right
......
......@@ -2576,7 +2576,7 @@ Consider this
If we make a join point with c but not c# we get
$j = \c -> ....c....
But if later inlining scrutines the c, thus
But if later inlining scrutinises the c, thus
$j = \c -> ... case c of { I# y -> ... } ...
......
......@@ -532,7 +532,7 @@ bug. The fix here is simply to decline to do w/w if that happens.
************************************************************************
* *
Type scrutiny that is specfic to demand analysis
Type scrutiny that is specific to demand analysis
* *
************************************************************************
......@@ -541,7 +541,7 @@ Note [Do not unpack class dictionaries]
If we have
f :: Ord a => [a] -> Int -> a
{-# INLINABLE f #-}
and we worker/wrapper f, we'll get a worker with an INLINALBE pragma
and we worker/wrapper f, we'll get a worker with an INLINABLE pragma
(see Note [Worker-wrapper for INLINABLE functions] in WorkWrap), which
can still be specialised by the type-class specialiser, something like
fw :: Ord a => [a] -> Int# -> a
......
......@@ -1785,7 +1785,7 @@ tcHsPartialSigType
-> LHsSigWcType Name -- The type signature
-> TcM ( [(Name, TcTyVar)] -- Wildcards
, Maybe TcTyVar -- Extra-constraints wildcard
, [TcTyVar] -- Implicitly and explicitly bound type varialbes
, [TcTyVar] -- Implicitly and explicitly bound type variables
, TcThetaType -- Theta part
, TcType ) -- Tau part
tcHsPartialSigType ctxt sig_ty
......
......@@ -2565,8 +2565,8 @@ Consider f1 = (Given, ReprEq)
f = (Derived, ReprEq)
I thought maybe we could never get Derived ReprEq constraints, but
we can; straight from the Wanteds during improvment. And from a Derived
ReprEq we could conceivably get a Derived NomEq improvment (by decomposing
we can; straight from the Wanteds during improvement. And from a Derived
ReprEq we could conceivably get a Derived NomEq improvement (by decomposing
a type constructor with Nomninal role), and hence unify.
-}
......
......@@ -423,7 +423,7 @@ emptyInert
{- Note [Solved dictionaries]
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
When we apply a top-level instance declararation, we add the "solved"
When we apply a top-level instance declaration, we add the "solved"
dictionary to the inert_solved_dicts. In general, we use it to avoid
creating a new EvVar when we have a new goal that we have solved in
the past.
......
......@@ -953,7 +953,7 @@ over them, for two reasons
add it to the ic_skols of the residual implication.
Note that we /only/ do this to the residual implication. We don't
complicate the quantified type varialbes of 'f' for downstream code;
complicate the quantified type variables of 'f' for downstream code;
it's just a device to make the error message generator know what to
report.
......
......@@ -3,7 +3,7 @@
(c) The GRASP/AQUA Project, Glasgow University, 1992-1999
Analysis functions over data types. Specficially, detecting recursive types.
Analysis functions over data types. Specifically, detecting recursive types.
This stuff is only used for source-code decls; it's recorded in interface
files for imported data types.
......
......@@ -533,7 +533,7 @@ data TyCon
}
-- | Algebraic data types, from
-- - @data@ declararations
-- - @data@ declarations
-- - @newtype@ declarations
-- - data instance declarations
-- - type instance declarations
......
......@@ -566,7 +566,7 @@ above (Above p g1 q1) g2 q2 = above p g1 (above q1 g2 q2)
above p@(Beside{}) g q = aboveNest (reduceDoc p) g 0 (reduceDoc q)
above p g q = aboveNest p g 0 (reduceDoc q)
-- Specfication: aboveNest p g k q = p $g$ (nest k q)
-- Specification: aboveNest p g k q = p $g$ (nest k q)
aboveNest :: RDoc -> Bool -> Int -> RDoc -> RDoc
aboveNest _ _ k _ | k `seq` False = undefined
aboveNest NoDoc _ _ _ = NoDoc
......
......@@ -113,7 +113,7 @@ vVarApps lc (ve, le) vvs
(vs, ls) = unzip vvs
vCaseDEFAULT :: VExpr -- scrutiniy
vCaseDEFAULT :: VExpr -- scrutinee
-> VVar -- bnder
-> Type -- type of vectorised version
-> Type -- type of lifted version
......
......@@ -176,7 +176,7 @@ typedef struct _RTSStats {
// -----------------------------------
// Cumulative stats about time use
// (we use signed values here because due to inacuracies in timers
// (we use signed values here because due to inaccuracies in timers
// the values can occasionally go slightly negative)
// Total CPU time used by the mutator
......
......@@ -515,7 +515,7 @@ the stack. See Note [Overlapping global registers] for implications.
VFPv2/VFPv3/NEON registers
s0-s15/d0-d7/q0-q3 Argument / result/ scratch registers
s16-s31/d8-d15/q4-q7 callee-saved registers (must be preserved across
subrutine calls)
subroutine calls)
VFPv3/NEON registers (added to the VFPv2 registers set)
d16-d31/q8-q15 Argument / result/ scratch registers
......@@ -572,7 +572,7 @@ the stack. See Note [Overlapping global registers] for implications.
FPU/SIMD registers
s/d/q/v0-v7 Argument / result/ scratch registers
s/d/q/v8-v15 callee-saved registers (must be preserved across subrutine calls,
s/d/q/v8-v15 callee-saved registers (must be preserved across subroutine calls,
but only bottom 64-bit value needs to be preserved)
s/d/q/v16-v31 temporary registers
......
......@@ -86,7 +86,7 @@ data RTSStats = RTSStats {
-- -----------------------------------
-- Cumulative stats about time use
-- (we use signed values here because due to inacuracies in timers
-- (we use signed values here because due to inaccuracies in timers
-- the values can occasionally go slightly negative)
-- | Total CPU time used by the mutator
......
......@@ -1143,7 +1143,7 @@ ocRunInit_MachO ( ObjectCode *oc )
// flag. We should do this elsewhere in the Mach-O linker code
// too. Note that the system linker will *refuse* to honor
// sections which don't have this flag, so this could cause
// weird behavior divergence (albeit reproduceable).
// weird behavior divergence (albeit reproducible).
if (0 == strcmp(sections[i].sectname,"__mod_init_func")) {
char *init_startC = image + sections[i].offset;
init_t *init = (init_t*)init_startC;
......
......@@ -4,7 +4,7 @@ include $(TOP)/mk/test.mk
.PHONY: gadt17 gadt23
# A mulit-module test that made GHC 6.4.1 crash
# A multi-module test that made GHC 6.4.1 crash
gadt17:
@$(RM) gadt17.hi Gadt17_help.hi
@$(RM) A$(OBJSUFFIX)
......
......@@ -39,7 +39,7 @@ safeRecomp01:
cleanSafeRecomp02:
rm -rf SafeRecomp02 SafeRecomp02.o SafeRecomp02.hi SafeRecomp02_A.o SafeRecomp02_A.hi
# mutli module program
# multi module program
safeRecomp02:
$(MAKE) -s --no-print-directory cleanSafeRecomp02
......
Markdown is supported
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment