diff options
Diffstat (limited to 'compiler/GHC/Driver')
| -rw-r--r-- | compiler/GHC/Driver/Env/KnotVars.hs | 6 | ||||
| -rw-r--r-- | compiler/GHC/Driver/Flags.hs | 2 | ||||
| -rw-r--r-- | compiler/GHC/Driver/GenerateCgIPEStub.hs | 2 | ||||
| -rw-r--r-- | compiler/GHC/Driver/Main.hs | 2 | ||||
| -rw-r--r-- | compiler/GHC/Driver/Make.hs | 12 | ||||
| -rw-r--r-- | compiler/GHC/Driver/MakeFile.hs | 2 | ||||
| -rw-r--r-- | compiler/GHC/Driver/Pipeline.hs | 2 | ||||
| -rw-r--r-- | compiler/GHC/Driver/Pipeline/Execute.hs | 8 | ||||
| -rw-r--r-- | compiler/GHC/Driver/Session.hs | 8 |
9 files changed, 22 insertions, 22 deletions
diff --git a/compiler/GHC/Driver/Env/KnotVars.hs b/compiler/GHC/Driver/Env/KnotVars.hs index e6d6c8a4d7..df744d4582 100644 --- a/compiler/GHC/Driver/Env/KnotVars.hs +++ b/compiler/GHC/Driver/Env/KnotVars.hs @@ -57,7 +57,7 @@ Initially 'KnotVars' was just a 'ModuleEnv a' but there is one tricky use of the data structure in 'mkDsEnvs' which required this generalised structure. In interactive mode the TypeEnvs from all the previous statements are merged -togethed into one big TypeEnv. 'dsLookupVar' relies on `tcIfaceVar'. The normal +together into one big TypeEnv. 'dsLookupVar' relies on `tcIfaceVar'. The normal lookup functions either look in the HPT or EPS but there is no entry for the `Ghci<N>` modules in either, so the whole merged TypeEnv for all previous Ghci* is stored in the `if_rec_types` variable and then lookup checks there in the case of any interactive module. @@ -71,7 +71,7 @@ Note [KnotVars: Why store the domain?] Normally there's a 'Module' at hand to tell us which 'TypeEnv' we want to interrogate at a particular time, apart from one case, when constructing the in-scope set -when linting an unfolding. In this case the whole environemnt is needed to tell us +when linting an unfolding. In this case the whole environment is needed to tell us everything that's in-scope at top-level in the loop because whilst we are linting unfoldings the top-level identifiers from modules in the cycle might not be globalised properly yet. @@ -89,7 +89,7 @@ There is a simple invariant which should hold for the KnotVars constructor: This invariant is difficult to test but easy to check using ghc-debug. The usage of NoKnotVars is intended to make this invariant easier to check. -The most common situation where a KnotVars is retained accidently is if a HscEnv +The most common situation where a KnotVars is retained accidentally is if a HscEnv which contains reference to a KnotVars is used during interface file loading. The thunks created during this process will retain a reference to the KnotVars. In theory, all these references should be removed by 'maybeRehydrateAfter' as that rehydrates all diff --git a/compiler/GHC/Driver/Flags.hs b/compiler/GHC/Driver/Flags.hs index fd23d2e81e..9f3c14524f 100644 --- a/compiler/GHC/Driver/Flags.hs +++ b/compiler/GHC/Driver/Flags.hs @@ -362,7 +362,7 @@ data GeneralFlag | Opt_VersionMacros | Opt_WholeArchiveHsLibs -- copy all libs into a single folder prior to linking binaries - -- this should elivate the excessive command line limit restrictions + -- this should alleviate the excessive command line limit restrictions -- on windows, by only requiring a single -L argument instead of -- one for each dependency. At the time of this writing, gcc -- forwards all -L flags to the collect2 command without using a diff --git a/compiler/GHC/Driver/GenerateCgIPEStub.hs b/compiler/GHC/Driver/GenerateCgIPEStub.hs index 6f5de8af4a..647457d44c 100644 --- a/compiler/GHC/Driver/GenerateCgIPEStub.hs +++ b/compiler/GHC/Driver/GenerateCgIPEStub.hs @@ -43,7 +43,7 @@ Stacktraces can be created from return frames as they are pushed to stack for ev But to make them readable / meaningful, one needs to know the source location of each return frame. Every return frame has a distinct info table and thus a distinct code pointer (for tables next to -code) or at least a distict address itself. Info Table Provernance Entries (IPE) are searchable by +code) or at least a distinct address itself. Info Table Provenance Entries (IPEs) are searchable by this pointer and contain a source location. The info table / info table code pointer to source location map is described in: diff --git a/compiler/GHC/Driver/Main.hs b/compiler/GHC/Driver/Main.hs index 546fbda015..aa7fd59889 100644 --- a/compiler/GHC/Driver/Main.hs +++ b/compiler/GHC/Driver/Main.hs @@ -1639,7 +1639,7 @@ hscSimplify' plugins ds_result = do -- Interface generators -------------------------------------------------------------- --- | Generate a striped down interface file, e.g. for boot files or when ghci +-- | Generate a stripped down interface file, e.g. for boot files or when ghci -- generates interface files. See Note [simpleTidyPgm - mkBootModDetailsTc] hscSimpleIface :: HscEnv -> TcGblEnv diff --git a/compiler/GHC/Driver/Make.hs b/compiler/GHC/Driver/Make.hs index d1f9ba0104..cb0efac6ad 100644 --- a/compiler/GHC/Driver/Make.hs +++ b/compiler/GHC/Driver/Make.hs @@ -861,9 +861,9 @@ a pair of an `IO a` action and a `MVar a`, where to place the result. blocking. * runPipelines takes this list and eventually passes it to runLoop which executes each action and places the result into the right MVar. -* The amount of parrelism is controlled by a semaphore. This is just used around the +* The amount of parallelism is controlled by a semaphore. This is just used around the module compilation step, so that only the right number of modules are compiled at - the same time which reduces overal memory usage and allocations. + the same time which reduces overall memory usage and allocations. * Each proper node has a LogQueue, which dictates where to send it's output. * The LogQueue is placed into the LogQueueQueue when the action starts and a worker thread processes the LogQueueQueue printing logs for each module in a stable order. @@ -992,7 +992,7 @@ mkBuildResult = BuildResult data BuildLoopState = BuildLoopState { buildDep :: M.Map NodeKey BuildResult -- The current way to build a specific TNodeKey, without cycles this just points to - -- the appropiate result of compiling a module but with + -- the appropriate result of compiling a module but with -- cycles there can be additional indirection and can point to the result of typechecking a loop , nNODE :: Int , hug_var :: MVar HomeUnitGraph @@ -2414,7 +2414,7 @@ executeCompileNode k n !old_hmi hug mrehydrate_mods mod = do -- Localise the hsc_env to use the cached flags hscSetFlags lcl_dynflags $ hydrated_hsc_env - -- Compile the module, locking with a semphore to avoid too many modules + -- Compile the module, locking with a semaphore to avoid too many modules -- being compiled at the same time leading to high memory usage. wrapAction lcl_hsc_env $ do res <- upsweep_mod lcl_hsc_env env_messager old_hmi mod k n @@ -2634,7 +2634,7 @@ X.hs module X where ``` If in `--make` we compile R.hs-boot, then A.hs, then X.hs, we'll get a `ModDetails` for `X` that has an AbstractTyCon for `T` in the the argument type of `MkX`. So: -* Either we should delay compiling X until after R has beeen compiled. (This is what we do) +* Either we should delay compiling X until after R has been compiled. (This is what we do) * Or we should rehydrate X after compiling R -- because it transitively depends on R.hs-boot. Ticket #20200 has exposed some issues to do with the knot-tying logic in GHC.Make, in `--make` mode. @@ -2846,7 +2846,7 @@ runAllPipelines n_jobs env acts = do MC.bracket spawn_actions kill_actions $ \_ -> do mapM_ waitMakeAction acts --- | Execute each action in order, limiting the amount of parrelism by the given +-- | Execute each action in order, limiting the amount of parallelism by the given -- semaphore. runLoop :: (((forall a. IO a -> IO a) -> IO ()) -> IO a) -> MakeEnv -> [MakeAction] -> IO [a] runLoop _ _env [] = return [] diff --git a/compiler/GHC/Driver/MakeFile.hs b/compiler/GHC/Driver/MakeFile.hs index 35a429a7d4..a770637311 100644 --- a/compiler/GHC/Driver/MakeFile.hs +++ b/compiler/GHC/Driver/MakeFile.hs @@ -261,7 +261,7 @@ processDeps dflags hsc_env excl_mods root hdl (AcyclicSCC (ModuleNode _ node)) -- Emit a dependency for each CPP import ; when (depIncludeCppDeps dflags) $ do - -- CPP deps are descovered in the module parsing phase by parsing + -- CPP deps are discovered in the module parsing phase by parsing -- comment lines left by the preprocessor. -- Note that GHC.parseModule may throw an exception if the module -- fails to parse, which may not be desirable (see #16616). diff --git a/compiler/GHC/Driver/Pipeline.hs b/compiler/GHC/Driver/Pipeline.hs index 0ebe1f792f..1ab60387f1 100644 --- a/compiler/GHC/Driver/Pipeline.hs +++ b/compiler/GHC/Driver/Pipeline.hs @@ -897,7 +897,7 @@ The idea in the future is that we can now implement different instiations of `TPipelineClass` to give different behaviours that the default `HookedPhase` implementation: * Additional logging of different phases -* Automatic parrelism (in the style of shake) +* Automatic parallelism (in the style of shake) * Easy consumption by external tools such as ghcide * Easier to create your own pipeline and extend existing pipelines. diff --git a/compiler/GHC/Driver/Pipeline/Execute.hs b/compiler/GHC/Driver/Pipeline/Execute.hs index 72a9e49278..b3737dc7e8 100644 --- a/compiler/GHC/Driver/Pipeline/Execute.hs +++ b/compiler/GHC/Driver/Pipeline/Execute.hs @@ -584,7 +584,7 @@ runUnlitPhase hsc_env input_fn output_fn = do -- Unicode or anything else (so we don't use Util.charToC -- here). If we get this wrong, then in -- GHC.HsToCore.Ticks.isGoodTickSrcSpan where we check that the filename in - -- a SrcLoc is the same as the source filenaame, the two will + -- a SrcLoc is the same as the source filename, the two will -- look bogusly different. See test: -- libraries/hpc/tests/function/subdir/tough2.hs escape ('\\':cs) = '\\':'\\': escape cs @@ -838,7 +838,7 @@ getOutputFilename logger tmpfs stop_phase output basename dflags next_phase mayb | StopLn <- next_phase, Just loc <- maybe_location = return $ if dynamicNow dflags then ml_dyn_obj_file loc else ml_obj_file loc - -- 2. If output style is persistant then + -- 2. If output style is persistent then | is_last_phase, Persistent <- output = persistent_fn -- 3. Specific file is only set when outputFile is set by -o -- If we are in dynamic mode but -dyno is not set then write to the same path as @@ -1138,7 +1138,7 @@ none of this can be used in that case. Note [Object merging] ~~~~~~~~~~~~~~~~~~~~~ On most platforms one can "merge" a set of relocatable object files into a new, -partiall-linked-but-still-relocatable object. In a typical UNIX-style linker, +partially-linked-but-still-relocatable object. In a typical UNIX-style linker, this is accomplished with the `ld -r` command. We rely on this for two ends: * We rely on `ld -r` to squash together split sections, making GHCi loading @@ -1369,7 +1369,7 @@ Introduction At some point during compilation with -fhpc, in the function `GHC.HsToCore.Ticks.isGoodTickSrcSpan`, we compare the filename that a `SrcSpan` refers to with the name of the file we are currently compiling. - For some reason I don't yet understand, they can sometimes legitimally be + For some reason I don't yet understand, they can sometimes legitimately be different, and then hpc ignores that SrcSpan. Problem diff --git a/compiler/GHC/Driver/Session.hs b/compiler/GHC/Driver/Session.hs index 9d03c434f6..db25fc7bc7 100644 --- a/compiler/GHC/Driver/Session.hs +++ b/compiler/GHC/Driver/Session.hs @@ -415,7 +415,7 @@ flattenIncludes specs = Build systems with a remote cache like Bazel or Buck (or Shake, see #16956) store the build artifacts produced by a build BA for reuse in subsequent builds. - Embedding source paths in interface fingerprints will thwart these attemps and + Embedding source paths in interface fingerprints will thwart these attempts and lead to unnecessary recompilations when the source paths in BA differ from the source paths in subsequent builds. -} @@ -742,7 +742,7 @@ data DynFlags = DynFlags { 'doFloatFromRhs'; with this we can control floating out with GHC flags. This addresses https://gitlab.haskell.org/ghc/ghc/-/issues/13663 and - allows for experminentation. + allows for experimentation. -} class HasDynFlags m where @@ -773,7 +773,7 @@ class ContainsDynFlags t where extractDynFlags :: t -> DynFlags ----------------------------------------------------------------------------- --- Accessessors from 'DynFlags' +-- Accessors from 'DynFlags' -- | "unbuild" a 'Settings' from a 'DynFlags'. This shouldn't be needed in the -- vast majority of code. But GHCi questionably uses this to produce a default @@ -2382,7 +2382,7 @@ dynamic_flags_deps = [ , make_ord_flag defFlag "fdiagnostics-color=never" (NoArg (upd (\d -> d { useColor = Never }))) - -- Suppress all that is suppressable in core dumps. + -- Suppress all that is suppressible in core dumps. -- Except for uniques, as some simplifier phases introduce new variables that -- have otherwise identical names. , make_ord_flag defGhcFlag "dsuppress-all" |