Frontend plugins
A frontend plugin adds a new major mode to GHC, like --make
, --abi-hash
, etc. This will be useful for GHC API clients, because GHC's frontend ghc/Main.hs
handles a lot of plumbing (flag parsing, setting up the session) which otherwise is painful to reimplement in GHC API (worse yet, it rapidly changes between GHC versions). For example, suppose someone wants to reimplement --make
using the Shake library. They would define a frontend plugin which implements the --shake
major mode.
Here's how it will work:
- A frontend plugin is a module which exports a single identifier
frontendPlugin
of typeGhcPlugins.FrontendPlugin
. This data structure has the following form:
type FrontendPluginAction
= [CommandLineOption] -> [(String, Maybe Phase)] -> GHC ()
data FrontendPlugin = FrontendPlugin {
frontendPluginAction :: FrontendPluginAction,
-- possibly more fields
}
defaultFrontendPlugin :: FrontendPluginAction -> FrontendPlugin
- There is a new major mode,
--frontend Foo.Plugin
, which loads and runs your plugin. You can pass extra flags to the plugin using-ffrontend-opt
.
We reuse the dynamic loading facilities for normal plugin loading.
This should be relatively easy to backport.
Possible design flex points:
- Here, you only load the plugin that you actually want to run. You could also imagine loading a plugin adding a new major mode flag.
- An alternative to having a full-on plugin architecture is to lib-ify most of
ghc/Main.hs
, so that other clients can use it but with different sets of options, etc.
Trac metadata
Trac field | Value |
---|---|
Version | 7.11 |
Type | FeatureRequest |
TypeOfFailure | OtherFailure |
Priority | normal |
Resolution | Unresolved |
Component | GHC API |
Test case | |
Differential revisions | |
BlockedBy | |
Related | |
Blocking | |
CC | |
Operating system | |
Architecture |