ghc-9.0.2: The GHC API
Safe HaskellSafe-Inferred
LanguageHaskell2010

GHC.Driver.Pipeline

Synopsis

Documentation

preprocess Source #

Arguments

:: HscEnv 
-> FilePath

input filename

-> Maybe InputFileBuffer

optional buffer to use instead of reading the input file

-> Maybe Phase

starting phase

-> IO (Either ErrorMessages (DynFlags, FilePath)) 

Just preprocess a file, put the result in a temp. file (used by the compilation manager during the summary phase).

We return the augmented DynFlags, because they contain the result of slurping in the OPTIONS pragmas

compileOne Source #

Arguments

:: HscEnv 
-> ModSummary

summary for module being compiled

-> Int

module N ...

-> Int

... of M

-> Maybe ModIface

old interface, if we have one

-> Maybe Linkable

old linkable, if we have one

-> SourceModified 
-> IO HomeModInfo

the complete HomeModInfo, if successful

Compile

Compile a single module, under the control of the compilation manager.

This is the interface between the compilation manager and the compiler proper (hsc), where we deal with tedious details like reading the OPTIONS pragma from the source file, converting the C or assembly that GHC produces into an object file, and compiling FFI stub files.

NB. No old interface can also mean that the source has changed.

compileOne' Source #

Arguments

:: Maybe TcGblEnv 
-> Maybe Messager 
-> HscEnv 
-> ModSummary

summary for module being compiled

-> Int

module N ...

-> Int

... of M

-> Maybe ModIface

old interface, if we have one

-> Maybe Linkable

old linkable, if we have one

-> SourceModified 
-> IO HomeModInfo

the complete HomeModInfo, if successful

data PhasePlus Source #

Instances

Instances details
Outputable PhasePlus Source # 
Instance details

Defined in GHC.Driver.Pipeline.Monad

newtype CompPipeline a Source #

Constructors

P 

Fields

data PipeEnv Source #

Constructors

PipeEnv 

Fields

data PipeState Source #

Constructors

PipeState 

Fields

  • hsc_env :: HscEnv

    only the DynFlags change in the HscEnv. The DynFlags change at various points, for example when we read the OPTIONS_GHC pragmas in the Cpp phase.

  • maybe_loc :: Maybe ModLocation

    the ModLocation. This is discovered during compilation, in the Hsc phase where we read the module header.

  • foreign_os :: [FilePath]

    additional object files resulting from compiling foreign code. They come from two sources: foreign stubs, and add{C,Cxx,Objc,Objcxx}File from template haskell

  • iface :: Maybe ModIface

    Interface generated by HscOut phase. Only available after the phase runs.

phaseOutputFilename :: Phase -> CompPipeline FilePath Source #

Computes the next output filename after we run next_phase. Like getOutputFilename, but it operates in the CompPipeline monad (which specifies all of the ambient information.)

getOutputFilename :: Phase -> PipelineOutput -> String -> DynFlags -> Phase -> Maybe ModLocation -> IO FilePath Source #

Computes the next output filename for something in the compilation pipeline. This is controlled by several variables:

  1. Phase: the last phase to be run (e.g. stopPhase). This is used to tell if we're in the last phase or not, because in that case flags like -o may be important.
  2. PipelineOutput: is this intended to be a Temporary or Persistent build output? Temporary files just go in a fresh temporary name.
  3. String: what was the basename of the original input file?
  4. DynFlags: the obvious thing
  5. Phase: the phase we want to determine the output filename of.
  6. Maybe ModLocation: the ModLocation of the module we're compiling; this can be used to override the default output of an object file. (TODO: do we actually need this?)

hscPostBackendPhase :: HscSource -> HscTarget -> Phase Source #

What phase to run after one of the backend code generators has run

runPhase Source #

Arguments

:: PhasePlus

Run this phase

-> FilePath

name of the input file

-> DynFlags

for convenience, we pass the current dflags in

-> CompPipeline (PhasePlus, FilePath) 

Each phase in the pipeline returns the next phase to execute, and the name of the file in which the output was placed.

We must do things dynamically this way, because we often don't know what the rest of the phases will be until part-way through the compilation: for example, an {-# OPTIONS -fasm #-} at the beginning of a source file can change the latter stages of the pipeline from taking the LLVM route to using the native code generator.