GHC.Driver.Main

Initialize HscEnv from an optional top_dir path

Action to perform in backend compilation

Status of a module in incremental compilation

If the Linkable contains Core bindings loaded from an interface, replace them with a lazy IO thunk that compiles them to bytecode and foreign objects, using the supplied environment for type checking.

The laziness is necessary because this value is stored purely in a HomeModLinkable in the home package table, rather than some dedicated mutable state that would generate bytecode on demand, so we have to call this function even when we don't know that we'll need the bytecode.

In addition, the laziness has to be hidden inside BCOs because Linkable is used too generally, so that looking at the constructor to decide whether to discard it when linking native code would force the thunk otherwise, incurring a significant performance penalty.

This is sound because generateByteCode just depends on things already loaded in the interface file.

Return an IO that hydrates Core bindings and compiles them to bytecode if the interface contains any, using the supplied type env for typechecking.

Unlike initWholeCoreBindings, this does not use lazy IO. Instead, the IO is only evaluated (in get_link_deps) when it is clear that it will be used immediately (because we're linking TH with -fprefer-byte-code in oneshot mode), and the result is cached in LoaderState.

initWholeCoreBindings needs the laziness because it is used to populate HomeModInfo, which is done preemptively, in anticipation of downstream modules using the bytecode for TH in make mode, which might never happen.

Write interface files

Compile to hard-code.

Generate a ModuleByteCode and write it to disk if `-fwrite-byte-code` is enabled.

Generate a fresh ModuleByteCode for a given module but do not write it to disk.

Do the recompilation avoidance checks for both one-shot and --make modes This function is the *only* place in the compiler where we decide whether to recompile a module or not!

parse a file, returning the abstract syntax

Rename and typecheck a module, additionally returning the renamed syntax

Rename and typecheck a module, additionally returning the renamed syntax and the diagnostics produced.

Do Typechecking without throwing SourceError exception with -Werror

Convert a typechecked module to Core

Make a ModDetails from the results of typechecking. Used when typechecking only, as opposed to full compilation.

Run Core2Core simplifier. The list of String is a list of (Core) plugin module names added via TH (cf addCorePlugin).

Check that a module is safe to import.

We return True to indicate the import is safe and False otherwise although in the False case an exception may be thrown first.

Return if a module is trusted and the pkgs it depends on to be trusted.

Rename some import declarations

Lookup things in the compiler's environment

Compile a stmt all the way to an HValue, but don't run it

We return Nothing to indicate an empty statement (or comment only), not a parse error.

Compile a stmt all the way to an HValue, but don't run it

We return Nothing to indicate an empty statement (or comment only), not a parse error.

Typecheck an expression (but don't run it)

How should we infer a type? See Note [TcRnExprMode]

Find the kind of a type, after generalisation

Run Core2Core simplifier. The list of String is a list of (Core) plugin module names added via TH (cf addCorePlugin).

Deal with errors and warnings returned by a compilation step

In order to reduce dependencies to other parts of the compiler, functions outside the "main" parts of GHC return warnings and errors as a parameter and signal success via by wrapping the result in a Maybe type. This function logs the returned warnings and propagates errors as exceptions (of type SourceError).

This function assumes the following invariants:

1. If the second result indicates success (is of the form 'Just x'), there must be no error messages in the first result.

2. If there are no error messages, but the second result indicates failure there should be warnings in the first result. That is, if the action failed, it must have been due to the warnings (i.e., -Werror).

genModDetails is used to initialise ModDetails at the end of compilation. This has two main effects: 1. Increases memory usage by unloading a lot of the TypeEnv 2. Globalising certain parts (DFunIds) in the TypeEnv (which used to be achieved using UpdateIdInfos) For the second part to work, it's critical that we use initIfaceLoadModule here rather than initIfaceCheck as initIfaceLoadModule removes the module from the KnotVars, otherwise name lookups succeed by hitting the old TypeEnv, which missing out the critical globalisation step for DFuns.