IO package:ghc

The IO Monad with an environment The environment is passed around as a Reader monad but as its in the IO monad, mutable references can be used for updating state.
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).
GHC's own exception type error messages all take the form:
<location>: <error>

If the location is on the command line, or in GHC itself, then <location>="ghc". All of the error types below correspond to a <location> of "ghc", except for ProgramError (where the string is assumed to contain a location already, so we don't print one).
An installation problem.
Module Location Where a module lives on the file system: the actual locations of the .hs, .hi, .dyn_hi, .o, .dyn_o and .hie files, if we have them. For a module in another unit, the ml_hs_file_ospath and ml_obj_file_ospath components of ModLocation are undefined. The locations specified by a ModLocation may or may not correspond to actual files yet: for example, even if the object file doesn't exist, the ModLocation still contains the path to where the object file will reside if/when it is created. The paths of anything which can affect recompilation should be placed inside ModLocation. When a ModLocation is created none of the filepaths will have -boot suffixes. This is because in --make mode the ModLocation is put in the finder cache which is indexed by ModuleName, when a ModLocation is retrieved from the FinderCache the boot suffixes are appended. The other case is in -c mode, there the ModLocation immediately gets given the boot suffixes in mkOneShotModLocation.