Commit 08a6fc69 authored by Gabor Greif's avatar Gabor Greif 💬
Browse files

Spelling in comments only [ci skip]

parent eb6ccb7c
......@@ -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.
--
......
......@@ -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)
......
......@@ -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
......
......@@ -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
......
......@@ -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
......
......@@ -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) -> ... }
......
......@@ -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
......
......@@ -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;
}
......
......@@ -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.
*/
......
......@@ -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.
*/
......
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