A 'ModuleGraph' contains all the nodes from the home package (only). See 'ModuleGraphNode' for information about the nodes.

Modules need to be compiled. hs-boots need to be typechecked before the associated "real" module so modules with {-# SOURCE #-} imports can be built. Instantiations also need to be typechecked to ensure that the module fits the signature. Substantiation typechecking is roughly comparable to the check that the module and its hs-boot agree.

The graph is not necessarily stored in topologically-sorted order. Use topSortModuleGraph and flattenSCC to achieve this.

Why do we ever need to construct empty graphs? Is it because of one shot mode?

Construct a module graph. This function should be the only entry point for building a ModuleGraph, since it is supposed to be built once and never modified.

If you ever find the need to build a ModuleGraph iteratively, don't add insert and update functions to the API since they become footguns. Instead, design an API that allows iterative construction without posterior modification, perhaps like what is done for building arrays from mutable arrays.

A version of mkModuleGraph that checks the module graph for invariants.

A 'ModuleGraphNode' is a node in the 'ModuleGraph'. Edges between nodes mark dependencies arising from module imports and dependencies arising from backpack instantiations.

Collect the immediate dependencies of a ModuleGraphNode, optionally avoiding hs-boot dependencies. If the drop_hs_boot_nodes flag is False, and if this is a .hs and there is an equivalent .hs-boot, add a link from the former to the latter. This has the effect of detecting bogus cases where the .hs-boot depends on the .hs, by introducing a cycle. Additionally, it ensures that we will always process the .hs-boot before the .hs, and so the HomePackageTable will always have the most up to date information.

A normal edge in the graph which isn't offset by an import stage.

Extract the Module from a ModuleNodeInfo

Extract the ModuleName from a ModuleNodeInfo

Extract the ModNodeKeyWithUid from a ModuleNodeInfo

Extract the HscSource from a ModuleNodeInfo, if we can determine it.

Extract the ModLocation from a ModuleNodeInfo

Extract the IsBootInterface from a ModuleNodeInfo

Returns the number of nodes in a ModuleGraph

Map a function f over all the ModSummaries. To preserve invariants, f can't change the isBoot status.

Map a function f over all the ModSummaries, in IO. To preserve invariants, f can't change the isBoot status.

Look up a non-boot ModSummary in the ModuleGraph.

Careful: Linear in the size of the module graph MP: This should probably be level aware

Lookup up a ModuleNameWithIsBoot in the ModuleGraph.

Multiple nodes in the ModuleGraph can have the same ModuleName and IsBootInterface.

Careful: Linear in the size of the module graph.

A function you should not need to use, or desire to use. Only used in one place, Load to facilitate a misimplementation in Backpack.

Return all nodes reachable from the given NodeKey.

Nothing if the key couldn't be found in the graph.

Things which are reachable if hs-boot files are ignored. Used by getLinkDeps

Reachability Query.

mgQuery(g, a, b) asks: Can we reach b from a in graph g?

Both a and b must be in g.

The ZeroScopeKey indicates the different scopes which we can refer to in a zero-scope query.

mgQueryZero g root b answers the question: can we reach b from root in the module graph g, only using normal (level 0) imports?

Many roots reachability Query.

mgQuery(g, roots, b) asks: Can we reach b from any of the roots in graph g?

Node b must be in g.

Many roots reachability Query.

mgQuery(g, roots, b) asks: Can we reach b from any of the roots in graph g, only using normal (level 0) imports?

Node b must be in g.

Turn a list of graph nodes into an efficient queriable graph. The first boolean parameter indicates whether nodes corresponding to hs-boot files should be collapsed into their relevant hs nodes.

This function returns all the modules belonging to the home-unit that can be reached by following the given dependencies. Additionally, if both the boot module and the non-boot module can be reached, it only returns the non-boot one.

This function filters out all the instantiation nodes from each SCC of a topological sort. Use this with care, as the resulting "strongly connected components" may not really be strongly connected in a direct way, as instantiations have been removed. It would probably be best to eliminate uses of this function where possible.

Turn a list of graph nodes into an efficient queriable graph. This graph only has edges between level-0 imports

This query answers the question. If I am looking at level n in module M then which modules are visible?

If you are looking at level -1 then the reachable modules are those imported at splice and then any modules those modules import at zero. (Ie the zero scope for those modules)

Transitive dependencies, but with the stage that each module is required at.

Already InstalledModules are always NotBoot

ImportLevel