HscEnv is like Session, except that some of the fields are immutable. An HscEnv is used to compile a single module from plain Haskell source code (after preprocessing) to either C, assembly or C--. It's also used to store the dynamic linker state to allow for multiple linkers in the same address space. Things like the module graph don't change during a single compilation.

Historical note: "hsc" used to be the name of the compiler binary, when there was a separate driver and compiler. To compile a single module, the driver would invoke hsc on the source code... so nowadays we think of hsc as the layer of the compiler that deals with compiling a single module.

The home package table describes already-compiled home-package modules, excluding the module we are compiling right now. (In one-shot mode the current module is the only home-package module, so hsc_HPT is empty. All other modules count as "external-package" modules. However, even in GHCi mode, hi-boot interfaces are demand-loaded into the external-package table.)

hsc_HPT is not mutable because we only demand-load external packages; the home package is eagerly loaded, module by module, by the compilation manager.

The HPT may contain modules compiled earlier by --make but not actually below the current module in the dependency graph.

(This changes a previous invariant: changed Jan 05.)

Interactive context, recording information about the state of the context in which statements are executed in a GHCi session.

Set the DynFlags used to evaluate interactive expressions. Also initialise (load) plugins.

Note: this cannot be used for changes to packages. Use setSessionDynFlags, or setProgramDynFlags and then copy the unitState into the interactive DynFlags.

The dynamic flag settings

Information about the currently loaded external packages. This is mutable because packages will be demand-loaded during a compilation run as required.

Logger

Temporary files

Unit environment (unit state, home unit, etc.).

Initialized from the databases cached in hsc_unit_dbs and from the DynFlags.

Hooks

Temporary file-system

Make a module in home unit

Target home unit-id

We don't want to generate object code so we compile to bytecode (HscInterpreted) which implies LinkInMemory HscInterpreted

Test if Safe Imports are on in some form

A way

Don't change the constructor order as it us used by waysTag to create a unique tag (e.g. thr_debug_p) which is expected by other tools (e.g. Cabal).

Host "full" ways (i.e. ways that have an impact on the compilation, not RTS only ways).

These ways must be used when compiling codes targeting the internal interpreter.

Turn these flags on when enabling this way

Turn these flags off when enabling this way

Code generation backends.

GHC supports several code generation backends serving different purposes (producing machine code, producing ByteCode for the interpreter) and supporting different platforms.