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.

This function checks then important property that if both p and q are home units then any dependency of p, which transitively depends on q is also a home unit.

See Note [Multiple Home Units], section 'Closure Property'.

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 backend (see backend field) 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.

Collect the instantiations of dependencies to create InstantiationNode work graph nodes. These are used to represent the type checking that is done after all the free holes (sigs in current package) relevant to that instantiation are compiled. This is necessary to catch some instantiation errors.

In the future, perhaps more of the work of instantiation could be moved here, instead of shoved in with the module compilation nodes. That could simplify backpack, and maybe hs-boot too.

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 {-# SOURCE #-}`.

For a module modname of type HscSource, determine the list of extra "imports" of other requirements which should be considered part of the import of the requirement, because it transitively depends on those requirements by imports of modules from other packages. The situation is something like this:

unit p where signature X signature Y import X

unit q where dependency p[X=<A>,Y=<B>] signature A signature B

Although q's B does not directly import A, we still have to make sure we process A first, because the merging process will cause B to indirectly import A. This function finds the TRANSITIVE closure of all such imports we need to make.

Like implicitRequirements', but returns either the module name, if it is a free hole, or the instantiated unit the imported module is from, so that that instantiated unit can be processed and via the batch mod graph (rather than a transitive closure done here) all the free holes are still reachable.

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.