Documentation

Perform a dependency analysis starting from the current targets and update the session with the new module graph.

Dependency analysis entails parsing the import directives and may therefore require running certain preprocessors.

Note that each ModSummary in the module graph caches its DynFlags. These DynFlags are determined by the current session DynFlags and the OPTIONS and LANGUAGE pragmas of the parsed module. Thus if you want changes to the DynFlags to take effect you need to call this function again. In case of errors, just throw them.

Perform dependency analysis like in depanal. In case of errors, the errors and an empty module graph are returned.

Perform dependency analysis like depanal but return a partial module graph even in the face of problems with some modules.

Modules which have parse errors in the module header, failing preprocessors or other issues preventing them from being summarised will simply be absent from the returned module graph.

Unlike depanal this function will not update hsc_mod_graph with the new module graph.

Try to load the program. See LoadHowMuch for the different modes.

This function implements the core of GHC's --make mode. It preprocesses, compiles and loads the specified modules, avoiding re-compilation wherever possible. Depending on the target (see hscTarget) compiling and loading may result in files being created on disk.

Calls the defaultWarnErrLogger after each compiling each module, whether successful or not.

If errors are encountered during dependency analysis, the module depanalE returns together with the errors an empty ModuleGraph. After processing this empty ModuleGraph, the errors of depanalE are thrown. All other errors are reported using the defaultWarnErrLogger.

Generalized version of load which also supports a custom Messager (for reporting progress) and ModuleGraph (generally produced by calling depanal.

Describes which modules of the module graph need to be loaded.

Downsweep (dependency analysis)

Chase downwards from the specified root set, returning summaries for all home modules encountered. Only follow source-import links.

We pass in the previous collection of summaries, which is used as a cache to avoid recalculating a module summary if the source is unchanged.

The returned list of [ModSummary] nodes has one node for each home-package module, plus one for any hs-boot files. The imports of these nodes are all there, including the imports of non-home-package modules.

Topological sort of the module graph

Calculate SCCs of the module graph, possibly dropping the hi-boot nodes The resulting list of strongly-connected-components is in topologically sorted order, starting with the module(s) at the bottom of the dependency graph (ie compile them first) and ending with the ones at the top.

Drop hi-boot nodes (first boolean arg)?

• False: treat the hi-boot summaries as nodes of the graph, so the graph must be acyclic
• True: eliminate the hi-boot nodes, and instead pretend the a source-import of Foo is an import of Foo The resulting graph has no hi-boot nodes, but can be cyclic

Like ms_home_imps, but for SOURCE imports.

All of the (possibly) home module imports from a ModSummary; that is to say, each of these module names could be a home import if an appropriately named file existed. (This is in contrast to package qualified imports, which are guaranteed not to be home imports.)

Tests if an HscSource is a boot file, primarily for constructing elements of BuildModule. We conflate signatures and modules because they are bound in the same namespace; only boot interfaces can be disambiguated with `import {--}`.

findExtraSigImports, but in a convenient form for GHC.Driver.Make and GHC.Tc.Module.

Indicates whether a module name is referring to a boot interface (hs-boot file) or regular module (hs file). We need to treat boot modules specially when building compilation graphs, since they break cycles. Regular source files and signature files are treated equivalently.