GHC.Driver.Pipeline

Documentation

oneShot :: HscEnv -> Phase -> [(String, Maybe Phase)] -> IO ()

compileFile :: HscEnv -> Phase -> (FilePath, Maybe Phase) -> IO FilePath

linkBinary :: DynFlags -> [FilePath] -> [UnitId] -> IO ()

preprocess

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

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'

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

link :: GhcLink -> DynFlags -> Bool -> HomePackageTable -> IO SuccessFlag

data PhasePlus

Constructors

RealPhase Phase

HscOut HscSource ModuleName HscStatus

Instances

Outputable PhasePlus

Defined in GHC.Driver.Pipeline.Monad

Methods

ppr :: PhasePlus -> SDoc

pprPrec :: Rational -> PhasePlus -> SDoc

newtype CompPipeline a

Constructors

P

Fields

• unP :: PipeEnv -> PipeState -> IO (PipeState, a)

Instances

MonadIO CompPipeline

Defined in GHC.Driver.Pipeline.Monad

Methods

liftIO :: IO a -> CompPipeline a

Applicative CompPipeline

Defined in GHC.Driver.Pipeline.Monad

Methods

pure :: a -> CompPipeline a

(<*>) :: CompPipeline (a -> b) -> CompPipeline a -> CompPipeline b

liftA2 :: (a -> b -> c) -> CompPipeline a -> CompPipeline b -> CompPipeline c

(*>) :: CompPipeline a -> CompPipeline b -> CompPipeline b

(<*) :: CompPipeline a -> CompPipeline b -> CompPipeline a

Functor CompPipeline

Defined in GHC.Driver.Pipeline.Monad

Methods

fmap :: (a -> b) -> CompPipeline a -> CompPipeline b

(<$) :: a -> CompPipeline b -> CompPipeline a

Monad CompPipeline

Defined in GHC.Driver.Pipeline.Monad

Methods

(>>=) :: CompPipeline a -> (a -> CompPipeline b) -> CompPipeline b

(>>) :: CompPipeline a -> CompPipeline b -> CompPipeline b

return :: a -> CompPipeline a

HasDynFlags CompPipeline

Defined in GHC.Driver.Pipeline.Monad

Methods

getDynFlags :: CompPipeline DynFlags

data PipeEnv

Constructors

PipeEnv

Fields

• stop_phase :: Phase

  Stop just before this phase

• src_filename :: String

  basename of original input source

• src_basename :: String

  basename of original input source

• src_suffix :: String

  its extension

• output_spec :: PipelineOutput

  says where to put the pipeline output

data PipeState

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

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

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?)

getPipeState :: CompPipeline PipeState

getPipeEnv :: CompPipeline PipeEnv

hscPostBackendPhase :: HscSource -> HscTarget -> Phase

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

getLocation :: HscSource -> ModuleName -> CompPipeline ModLocation

setModLocation :: ModLocation -> CompPipeline ()

setDynFlags :: DynFlags -> CompPipeline ()

runPhase

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.

exeFileName :: Bool -> DynFlags -> FilePath

maybeCreateManifest :: DynFlags -> FilePath -> IO [FilePath]

doCpp :: DynFlags -> Bool -> FilePath -> FilePath -> IO ()

linkingNeeded :: DynFlags -> Bool -> [Linkable] -> [UnitId] -> IO Bool

checkLinkInfo :: DynFlags -> [UnitId] -> FilePath -> IO Bool

writeInterfaceOnlyMode :: DynFlags -> Bool