Fix recompilation checking of pure plugins
[ghc.git] / docs / users_guide / extending_ghc.rst
1 .. _extending-ghc:
2
3 Extending and using GHC as a Library
4 ====================================
5
6 GHC exposes its internal APIs to users through the built-in ghc package.
7 It allows you to write programs that leverage GHC's entire compilation
8 driver, in order to analyze or compile Haskell code programmatically.
9 Furthermore, GHC gives users the ability to load compiler plugins during
10 compilation - modules which are allowed to view and change GHC's
11 internal intermediate representation, Core. Plugins are suitable for
12 things like experimental optimizations or analysis, and offer a lower
13 barrier of entry to compiler development for many common cases.
14
15 Furthermore, GHC offers a lightweight annotation mechanism that you can
16 use to annotate your source code with metadata, which you can later
17 inspect with either the compiler API or a compiler plugin.
18
19 .. _annotation-pragmas:
20
21 Source annotations
22 ------------------
23
24 Annotations are small pragmas that allow you to attach data to
25 identifiers in source code, which are persisted when compiled. These
26 pieces of data can then inspected and utilized when using GHC as a
27 library or writing a compiler plugin.
28
29 .. _ann-pragma:
30
31 Annotating values
32 ~~~~~~~~~~~~~~~~~
33
34 .. index::
35    single: ANN pragma
36    single: pragma; ANN
37    single: source annotations
38
39 Any expression that has both ``Typeable`` and ``Data`` instances may be
40 attached to a top-level value binding using an ``ANN`` pragma. In
41 particular, this means you can use ``ANN`` to annotate data constructors
42 (e.g. ``Just``) as well as normal values (e.g. ``take``). By way of
43 example, to annotate the function ``foo`` with the annotation
44 ``Just "Hello"`` you would do this:
45
46 ::
47
48     {-# ANN foo (Just "Hello") #-}
49     foo = ...
50
51 A number of restrictions apply to use of annotations:
52
53 -  The binder being annotated must be at the top level (i.e. no nested
54    binders)
55
56 -  The binder being annotated must be declared in the current module
57
58 -  The expression you are annotating with must have a type with
59    ``Typeable`` and ``Data`` instances
60
61 -  The :ref:`Template Haskell staging restrictions <th-usage>` apply to the
62    expression being annotated with, so for example you cannot run a
63    function from the module being compiled.
64
65    To be precise, the annotation ``{-# ANN x e #-}`` is well staged if
66    and only if ``$(e)`` would be (disregarding the usual type
67    restrictions of the splice syntax, and the usual restriction on
68    splicing inside a splice - ``$([|1|])`` is fine as an annotation,
69    albeit redundant).
70
71 If you feel strongly that any of these restrictions are too onerous,
72 :ghc-wiki:`please give the GHC team a shout <MailingListsAndIRC>`.
73
74 However, apart from these restrictions, many things are allowed,
75 including expressions which are not fully evaluated! Annotation
76 expressions will be evaluated by the compiler just like Template Haskell
77 splices are. So, this annotation is fine:
78
79 ::
80
81     {-# ANN f SillyAnnotation { foo = (id 10) + $([| 20 |]), bar = 'f } #-}
82     f = ...
83
84 .. _typeann-pragma:
85
86 Annotating types
87 ~~~~~~~~~~~~~~~~
88
89 .. index::
90    single: ANN pragma; on types
91
92 You can annotate types with the ``ANN`` pragma by using the ``type``
93 keyword. For example:
94
95 ::
96
97     {-# ANN type Foo (Just "A `Maybe String' annotation") #-}
98     data Foo = ...
99
100 .. _modann-pragma:
101
102 Annotating modules
103 ~~~~~~~~~~~~~~~~~~
104
105 .. index::
106    single: ANN pragma; on modules
107
108 You can annotate modules with the ``ANN`` pragma by using the ``module``
109 keyword. For example:
110
111 ::
112
113     {-# ANN module (Just "A `Maybe String' annotation") #-}
114
115 .. _ghc-as-a-library:
116
117 Using GHC as a Library
118 ----------------------
119
120 The ``ghc`` package exposes most of GHC's frontend to users, and thus
121 allows you to write programs that leverage it. This library is actually
122 the same library used by GHC's internal, frontend compilation driver,
123 and thus allows you to write tools that programmatically compile source
124 code and inspect it. Such functionality is useful in order to write
125 things like IDE or refactoring tools. As a simple example, here's a
126 program which compiles a module, much like ghc itself does by default
127 when invoked:
128
129 ::
130
131     import GHC
132     import GHC.Paths ( libdir )
133     import DynFlags ( defaultFatalMessager, defaultFlushOut )
134
135     main =
136         defaultErrorHandler defaultFatalMessager defaultFlushOut $ do
137           runGhc (Just libdir) $ do
138             dflags <- getSessionDynFlags
139             setSessionDynFlags dflags
140             target <- guessTarget "test_main.hs" Nothing
141             setTargets [target]
142             load LoadAllTargets
143
144 The argument to ``runGhc`` is a bit tricky. GHC needs this to find its
145 libraries, so the argument must refer to the directory that is printed
146 by ``ghc --print-libdir`` for the same version of GHC that the program
147 is being compiled with. Above we therefore use the ``ghc-paths`` package
148 which provides this for us.
149
150 Compiling it results in:
151
152 .. code-block:: none
153
154     $ cat test_main.hs
155     main = putStrLn "hi"
156     $ ghc -package ghc simple_ghc_api.hs
157     [1 of 1] Compiling Main             ( simple_ghc_api.hs, simple_ghc_api.o )
158     Linking simple_ghc_api ...
159     $ ./simple_ghc_api
160     $ ./test_main
161     hi
162     $
163
164 For more information on using the API, as well as more samples and
165 references, please see `this Haskell.org wiki
166 page <http://haskell.org/haskellwiki/GHC/As_a_library>`__.
167
168 .. _compiler-plugins:
169
170 Compiler Plugins
171 ----------------
172
173 GHC has the ability to load compiler plugins at compile time. The
174 feature is similar to the one provided by
175 `GCC <http://gcc.gnu.org/wiki/plugins>`__, and allows users to write
176 plugins that can adjust the behaviour of the constraint solver, inspect
177 and modify the compilation pipeline, as well as transform and inspect
178 GHC's intermediate language, Core. Plugins are suitable for experimental
179 analysis or optimization, and require no changes to GHC's source code to
180 use.
181
182 Plugins cannot optimize/inspect C-\\-, nor can they implement things like
183 parser/front-end modifications like GCC, apart from limited changes to
184 the constraint solver. If you feel strongly that any of these
185 restrictions are too onerous,
186 :ghc-wiki:`please give the GHC team a shout <MailingListsAndIRC>`.
187
188 Plugins do not work with ``-fexternal-interpreter``. If you need to run plugins
189 with ``-fexternal-interpreter`` let GHC developers know in :ghc-ticket:`14335`.
190
191 .. _using-compiler-plugins:
192
193 Using compiler plugins
194 ~~~~~~~~~~~~~~~~~~~~~~
195
196 Plugins can be added on the command line with the :ghc-flag:`-fplugin=⟨module⟩`
197 option where ⟨module⟩ is a module in a registered package that exports the
198 plugin. Arguments can be passed to the plugins with the
199 :ghc-flag:`-fplugin-opt=⟨module⟩:⟨args⟩` option. The list of enabled plugins can
200 be reset with the :ghc-flag:`-fclear-plugins` option.
201
202 .. ghc-flag:: -fplugin=⟨module⟩
203     :shortdesc: Load a plugin exported by a given module
204     :type: dynamic
205     :category: plugins
206
207     Load the plugin in the given module. The module must be a member of a
208     package registered in GHC's package database.
209
210 .. ghc-flag:: -fplugin-opt=⟨module⟩:⟨args⟩
211     :shortdesc: Give arguments to a plugin module; module must be specified with
212         :ghc-flag:`-fplugin=⟨module⟩`
213     :type: dynamic
214     :category: plugins
215
216     Give arguments to a plugin module; module must be specified with
217     :ghc-flag:`-fplugin=⟨module⟩`.
218
219 .. ghc-flag:: -fclear-plugins
220     :shortdesc: Clear the list of active plugins
221     :type: dynamic
222     :category: plugins
223
224     Clear the list of plugins previously specified with
225     :ghc-flag:`-fplugin`. This is useful in GHCi where simply removing the
226     :ghc-flag:`-fplugin` options from the command line is not possible. Instead
227     `:set -fclear-plugins` can be used.
228
229
230 As an example, in order to load the plugin exported by ``Foo.Plugin`` in
231 the package ``foo-ghc-plugin``, and give it the parameter "baz", we
232 would invoke GHC like this:
233
234 .. code-block:: none
235
236     $ ghc -fplugin Foo.Plugin -fplugin-opt Foo.Plugin:baz Test.hs
237     [1 of 1] Compiling Main             ( Test.hs, Test.o )
238     Loading package ghc-prim ... linking ... done.
239     Loading package integer-gmp ... linking ... done.
240     Loading package base ... linking ... done.
241     Loading package ffi-1.0 ... linking ... done.
242     Loading package foo-ghc-plugin-0.1 ... linking ... done.
243     ...
244     Linking Test ...
245     $
246
247 Alternatively, core plugins can be specified with Template Haskell.
248
249 ::
250
251    addCorePlugin "Foo.Plugin"
252
253 This inserts the plugin as a core-to-core pass. Unlike `-fplugin=(module)`,
254 the plugin module can't reside in the same package as the module calling
255 :th-ref:`Language.Haskell.TH.Syntax.addCorePlugin`. This way, the
256 implementation can expect the plugin to be built by the time
257 it is needed.
258
259 Plugin modules live in a separate namespace from
260 the user import namespace.  By default, these two namespaces are
261 the same; however, there are a few command line options which
262 control specifically plugin packages:
263
264 .. ghc-flag:: -plugin-package ⟨pkg⟩
265     :shortdesc: Expose ⟨pkg⟩ for plugins
266     :type: dynamic
267     :category: plugins
268
269     This option causes the installed package ⟨pkg⟩ to be exposed for plugins,
270     such as :ghc-flag:`-fplugin=⟨module⟩`. The package ⟨pkg⟩ can be specified
271     in full with its version number (e.g.  ``network-1.0``) or the version
272     number can be omitted if there is only one version of the package
273     installed. If there are multiple versions of ⟨pkg⟩ installed and
274     :ghc-flag:`-hide-all-plugin-packages` was not specified, then all other
275     versions will become hidden.  :ghc-flag:`-plugin-package ⟨pkg⟩` supports
276     thinning and renaming described in :ref:`package-thinning-and-renaming`.
277
278     Unlike :ghc-flag:`-package ⟨pkg⟩`, this option does NOT cause package ⟨pkg⟩
279     to be linked into the resulting executable or shared object.
280
281 .. ghc-flag:: -plugin-package-id ⟨pkg-id⟩
282     :shortdesc: Expose ⟨pkg-id⟩ for plugins
283     :type: dynamic
284     :category: plugins
285
286     Exposes a package in the plugin namespace like :ghc-flag:`-plugin-package
287     ⟨pkg⟩`, but the package is named by its installed package ID rather than by
288     name.  This is a more robust way to name packages, and can be used to
289     select packages that would otherwise be shadowed. Cabal passes
290     :ghc-flag:`-plugin-package-id ⟨pkg-id⟩` flags to GHC.
291     :ghc-flag:`-plugin-package-id ⟨pkg-id⟩` supports thinning and renaming
292     described in :ref:`package-thinning-and-renaming`.
293
294 .. ghc-flag:: -hide-all-plugin-packages
295     :shortdesc: Hide all packages for plugins by default
296     :type: dynamic
297     :category: plugins
298
299     By default, all exposed packages in the normal, source import namespace are
300     also available for plugins.  This causes those packages to be hidden by
301     default.  If you use this flag, then any packages with plugins you require
302     need to be explicitly exposed using :ghc-flag:`-plugin-package ⟨pkg⟩`
303     options.
304
305 At the moment, the only way to specify a dependency on a plugin
306 in Cabal is to put it in ``build-depends`` (which uses the conventional
307 :ghc-flag:`-package-id ⟨unit-id⟩` flag); however, in the future there
308 will be a separate field for specifying plugin dependencies specifically.
309
310 .. _writing-compiler-plugins:
311
312 Writing compiler plugins
313 ~~~~~~~~~~~~~~~~~~~~~~~~
314
315 Plugins are modules that export at least a single identifier,
316 ``plugin``, of type ``GhcPlugins.Plugin``. All plugins should
317 ``import GhcPlugins`` as it defines the interface to the compilation
318 pipeline.
319
320 A ``Plugin`` effectively holds a function which installs a compilation
321 pass into the compiler pipeline. By default there is the empty plugin
322 which does nothing, ``GhcPlugins.defaultPlugin``, which you should
323 override with record syntax to specify your installation function. Since
324 the exact fields of the ``Plugin`` type are open to change, this is the
325 best way to ensure your plugins will continue to work in the future with
326 minimal interface impact.
327
328 ``Plugin`` exports a field, ``installCoreToDos`` which is a function of
329 type ``[CommandLineOption] -> [CoreToDo] -> CoreM [CoreToDo]``. A
330 ``CommandLineOption`` is effectively just ``String``, and a ``CoreToDo``
331 is basically a function of type ``Core -> Core``. A ``CoreToDo`` gives
332 your pass a name and runs it over every compiled module when you invoke
333 GHC.
334
335 As a quick example, here is a simple plugin that just does nothing and
336 just returns the original compilation pipeline, unmodified, and says
337 'Hello':
338
339 ::
340
341     module DoNothing.Plugin (plugin) where
342     import GhcPlugins
343
344     plugin :: Plugin
345     plugin = defaultPlugin {
346       installCoreToDos = install
347       }
348
349     install :: [CommandLineOption] -> [CoreToDo] -> CoreM [CoreToDo]
350     install _ todo = do
351       putMsgS "Hello!"
352       return todo
353
354 Provided you compiled this plugin and registered it in a package (with
355 cabal for instance,) you can then use it by just specifying
356 ``-fplugin=DoNothing.Plugin`` on the command line, and during the
357 compilation you should see GHC say 'Hello'.
358
359 .. _core-plugins-in-more-detail:
360
361 Core plugins in more detail
362 ~~~~~~~~~~~~~~~~~~~~~~~~~~~
363
364 ``CoreToDo`` is effectively a data type that describes all the kinds of
365 optimization passes GHC does on Core. There are passes for
366 simplification, CSE, etc. There is a specific case for
367 plugins, ``CoreDoPluginPass :: String -> PluginPass -> CoreToDo`` which
368 should be what you always use when inserting your own pass into the
369 pipeline. The first parameter is the name of the plugin, and the second
370 is the pass you wish to insert.
371
372 ``CoreM`` is a monad that all of the Core optimizations live and operate
373 inside of.
374
375 A plugin's installation function (``install`` in the above example)
376 takes a list of ``CoreToDo``\ s and returns a list of ``CoreToDo``.
377 Before GHC begins compiling modules, it enumerates all the needed
378 plugins you tell it to load, and runs all of their installation
379 functions, initially on a list of passes that GHC specifies itself.
380 After doing this for every plugin, the final list of passes is given to
381 the optimizer, and are run by simply going over the list in order.
382
383 You should be careful with your installation function, because the list
384 of passes you give back isn't questioned or double checked by GHC at the
385 time of this writing. An installation function like the following:
386
387 ::
388
389     install :: [CommandLineOption] -> [CoreToDo] -> CoreM [CoreToDo]
390     install _ _ = return []
391
392 is certainly valid, but also certainly not what anyone really wants.
393
394 .. _manipulating-bindings:
395
396 Manipulating bindings
397 ^^^^^^^^^^^^^^^^^^^^^
398
399 In the last section we saw that besides a name, a ``CoreDoPluginPass``
400 takes a pass of type ``PluginPass``. A ``PluginPass`` is a synonym for
401 ``(ModGuts -> CoreM ModGuts)``. ``ModGuts`` is a type that represents
402 the one module being compiled by GHC at any given time.
403
404 A ``ModGuts`` holds all of the module's top level bindings which we can
405 examine. These bindings are of type ``CoreBind`` and effectively
406 represent the binding of a name to body of code. Top-level module
407 bindings are part of a ``ModGuts`` in the field ``mg_binds``.
408 Implementing a pass that manipulates the top level bindings merely needs
409 to iterate over this field, and return a new ``ModGuts`` with an updated
410 ``mg_binds`` field. Because this is such a common case, there is a
411 function provided named ``bindsOnlyPass`` which lifts a function of type
412 ``([CoreBind] -> CoreM [CoreBind])`` to type
413 ``(ModGuts -> CoreM ModGuts)``.
414
415 Continuing with our example from the last section, we can write a simple
416 plugin that just prints out the name of all the non-recursive bindings
417 in a module it compiles:
418
419 ::
420
421     module SayNames.Plugin (plugin) where
422     import GhcPlugins
423
424     plugin :: Plugin
425     plugin = defaultPlugin {
426       installCoreToDos = install
427       }
428
429     install :: [CommandLineOption] -> [CoreToDo] -> CoreM [CoreToDo]
430     install _ todo = do
431       return (CoreDoPluginPass "Say name" pass : todo)
432
433     pass :: ModGuts -> CoreM ModGuts
434     pass guts = do dflags <- getDynFlags
435                    bindsOnlyPass (mapM (printBind dflags)) guts
436       where printBind :: DynFlags -> CoreBind -> CoreM CoreBind
437             printBind dflags bndr@(NonRec b _) = do
438               putMsgS $ "Non-recursive binding named " ++ showSDoc dflags (ppr b)
439               return bndr
440             printBind _ bndr = return bndr
441
442 .. _getting-annotations:
443
444 Using Annotations
445 ^^^^^^^^^^^^^^^^^
446
447 Previously we discussed annotation pragmas (:ref:`annotation-pragmas`),
448 which we mentioned could be used to give compiler plugins extra guidance
449 or information. Annotations for a module can be retrieved by a plugin,
450 but you must go through the modules ``ModGuts`` in order to get it.
451 Because annotations can be arbitrary instances of ``Data`` and
452 ``Typeable``, you need to give a type annotation specifying the proper
453 type of data to retrieve from the interface file, and you need to make
454 sure the annotation type used by your users is the same one your plugin
455 uses. For this reason, we advise distributing annotations as part of the
456 package which also provides compiler plugins if possible.
457
458 To get the annotations of a single binder, you can use
459 ``getAnnotations`` and specify the proper type. Here's an example that
460 will print out the name of any top-level non-recursive binding with the
461 ``SomeAnn`` annotation:
462
463 ::
464
465     {-# LANGUAGE DeriveDataTypeable #-}
466     module SayAnnNames.Plugin (plugin, SomeAnn(..)) where
467     import GhcPlugins
468     import Control.Monad (unless)
469     import Data.Data
470
471     data SomeAnn = SomeAnn deriving Data
472
473     plugin :: Plugin
474     plugin = defaultPlugin {
475       installCoreToDos = install
476       }
477
478     install :: [CommandLineOption] -> [CoreToDo] -> CoreM [CoreToDo]
479     install _ todo = do
480       return (CoreDoPluginPass "Say name" pass : todo)
481
482     pass :: ModGuts -> CoreM ModGuts
483     pass g = do
484               dflags <- getDynFlags
485               mapM_ (printAnn dflags g) (mg_binds g) >> return g
486       where printAnn :: DynFlags -> ModGuts -> CoreBind -> CoreM CoreBind
487             printAnn dflags guts bndr@(NonRec b _) = do
488               anns <- annotationsOn guts b :: CoreM [SomeAnn]
489               unless (null anns) $ putMsgS $ "Annotated binding found: " ++  showSDoc dflags (ppr b)
490               return bndr
491             printAnn _ _ bndr = return bndr
492
493     annotationsOn :: Data a => ModGuts -> CoreBndr -> CoreM [a]
494     annotationsOn guts bndr = do
495       anns <- getAnnotations deserializeWithData guts
496       return $ lookupWithDefaultUFM anns [] (varUnique bndr)
497
498 Please see the GHC API documentation for more about how to use internal
499 APIs, etc.
500
501 .. _typechecker-plugins:
502
503 Typechecker plugins
504 ~~~~~~~~~~~~~~~~~~~
505
506 In addition to Core plugins, GHC has experimental support for
507 typechecker plugins, which allow the behaviour of the constraint solver
508 to be modified. For example, they make it possible to interface the
509 compiler to an SMT solver, in order to support a richer theory of
510 type-level arithmetic expressions than the theory built into GHC (see
511 :ref:`typelit-tyfuns`).
512
513 The ``Plugin`` type has a field ``tcPlugin`` of type
514 ``[CommandLineOption] -> Maybe TcPlugin``, where the ``TcPlugin`` type
515 is defined thus:
516
517 ::
518
519     data TcPlugin = forall s . TcPlugin
520       { tcPluginInit  :: TcPluginM s
521       , tcPluginSolve :: s -> TcPluginSolver
522       , tcPluginStop  :: s -> TcPluginM ()
523       }
524
525     type TcPluginSolver = [Ct] -> [Ct] -> [Ct] -> TcPluginM TcPluginResult
526
527     data TcPluginResult = TcPluginContradiction [Ct] | TcPluginOk [(EvTerm,Ct)] [Ct]
528
529 (The details of this representation are subject to change as we gain
530 more experience writing typechecker plugins. It should not be assumed to
531 be stable between GHC releases.)
532
533 The basic idea is as follows:
534
535 -  When type checking a module, GHC calls ``tcPluginInit`` once before
536    constraint solving starts. This allows the plugin to look things up
537    in the context, initialise mutable state or open a connection to an
538    external process (e.g. an external SMT solver). The plugin can return
539    a result of any type it likes, and the result will be passed to the
540    other two fields.
541
542 -  During constraint solving, GHC repeatedly calls ``tcPluginSolve``.
543    This function is provided with the current set of constraints, and
544    should return a ``TcPluginResult`` that indicates whether a
545    contradiction was found or progress was made. If the plugin solver
546    makes progress, GHC will re-start the constraint solving pipeline,
547    looping until a fixed point is reached.
548
549 -  Finally, GHC calls ``tcPluginStop`` after constraint solving is
550    finished, allowing the plugin to dispose of any resources it has
551    allocated (e.g. terminating the SMT solver process).
552
553 Plugin code runs in the ``TcPluginM`` monad, which provides a restricted
554 interface to GHC API functionality that is relevant for typechecker
555 plugins, including ``IO`` and reading the environment. If you need
556 functionality that is not exposed in the ``TcPluginM`` module, you can
557 use ``unsafeTcPluginTcM :: TcM a -> TcPluginM a``, but are encouraged to
558 contact the GHC team to suggest additions to the interface. Note that
559 ``TcPluginM`` can perform arbitrary IO via
560 ``tcPluginIO :: IO a -> TcPluginM a``, although some care must be taken
561 with side effects (particularly in ``tcPluginSolve``). In general, it is
562 up to the plugin author to make sure that any IO they do is safe.
563
564 .. _constraint-solving-with-plugins:
565
566 Constraint solving with plugins
567 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
568
569 The key component of a typechecker plugin is a function of type
570 ``TcPluginSolver``, like this:
571
572 ::
573
574     solve :: [Ct] -> [Ct] -> [Ct] -> TcPluginM TcPluginResult
575     solve givens deriveds wanteds = ...
576
577 This function will be invoked at two points in the constraint solving
578 process: after simplification of given constraints, and after
579 unflattening of wanted constraints. The two phases can be distinguished
580 because the deriveds and wanteds will be empty in the first case. In
581 each case, the plugin should either
582
583 -  return ``TcPluginContradiction`` with a list of impossible
584    constraints (which must be a subset of those passed in), so they can
585    be turned into errors; or
586
587 -  return ``TcPluginOk`` with lists of solved and new constraints (the
588    former must be a subset of those passed in and must be supplied with
589    corresponding evidence terms).
590
591 If the plugin cannot make any progress, it should return
592 ``TcPluginOk [] []``. Otherwise, if there were any new constraints, the
593 main constraint solver will be re-invoked to simplify them, then the
594 plugin will be invoked again. The plugin is responsible for making sure
595 that this process eventually terminates.
596
597 Plugins are provided with all available constraints (including
598 equalities and typeclass constraints), but it is easy for them to
599 discard those that are not relevant to their domain, because they need
600 return only those constraints for which they have made progress (either
601 by solving or contradicting them).
602
603 Constraints that have been solved by the plugin must be provided with
604 evidence in the form of an ``EvTerm`` of the type of the constraint.
605 This evidence is ignored for given and derived constraints, which GHC
606 "solves" simply by discarding them; typically this is used when they are
607 uninformative (e.g. reflexive equations). For wanted constraints, the
608 evidence will form part of the Core term that is generated after
609 typechecking, and can be checked by ``-dcore-lint``. It is possible for
610 the plugin to create equality axioms for use in evidence terms, but GHC
611 does not check their consistency, and inconsistent axiom sets may lead
612 to segfaults or other runtime misbehaviour.
613
614 .. _source-plugins:
615
616 Source plugins
617 ~~~~~~~~~~~~~~
618
619 In addition to core and type checker plugins, you can install plugins that can
620 access different representations of the source code. The main purpose of these
621 plugins is to make it easier to implement development tools.
622
623 There are several different access points that you can use for defining plugins
624 that access the representations. All these fields receive the list of
625 ``CommandLineOption`` strings that are passed to the compiler using the
626 :ghc-flag:`-fplugin-opt` flags.
627
628 ::
629
630     plugin :: Plugin
631     plugin = defaultPlugin {
632         parsedResultAction = parsed
633       , typeCheckResultAction = typechecked
634       , spliceRunAction = spliceRun
635       , interfaceLoadAction = interfaceLoad
636       , renamedResultAction = renamed
637       }
638
639 Parsed representation
640 ^^^^^^^^^^^^^^^^^^^^^
641
642 When you want to define a plugin that uses the syntax tree of the source code,
643 you would like to override the ``parsedResultAction`` field. This access point
644 enables you to get access to information about the lexical tokens and comments
645 in the source code as well as the original syntax tree of the compiled module.
646
647 ::
648
649     parsed :: [CommandLineOption] -> ModSummary -> HsParsedModule
650                 -> Hsc HsParsedModule
651
652 The ``ModSummary`` contains useful
653 meta-information about the compiled module. The ``HsParsedModule`` contains the
654 lexical and syntactical information we mentioned before. The result that you
655 return will change the result of the parsing. If you don't want to change the
656 result, just return the ``HsParsedModule`` that you received as the argument.
657
658 Type checked representation
659 ^^^^^^^^^^^^^^^^^^^^^^^^^^^
660
661 When you want to define a plugin that needs semantic information about the
662 source code, use the ``typeCheckResultAction`` field. For example, if your
663 plugin have to decide if two names are referencing the same definition or it has
664 to check the type of a function it is using semantic information. In this case
665 you need to access the renamed or type checked version of the syntax tree with
666 ``typeCheckResultAction`` or ``renamedResultAction``.
667
668 ::
669
670     typechecked :: [CommandLineOption] -> ModSummary -> TcGblEnv -> TcM TcGblEnv
671     renamed :: [CommandLineOption] -> TcGblEnv -> HsGroup GhcRn -> TcM (TcGblEnv, HsGroup GhcRn)
672
673 By overriding the ``renamedResultAction`` field we can modify each ``HsGroup``
674 after it has been renamed. A source file is seperated into groups depending on
675 the location of template haskell splices so the contents of these groups may
676 not be intuitive. In order to save the entire renamed AST for inspection
677 at the end of typechecking you can set ``renamedResultAction`` to ``keepRenamedSource``
678 which is provided by the ``Plugins`` module.
679 This is important because some parts of the renamed
680 syntax tree (for example, imports) are not found in the typechecked one.
681
682
683
684 Evaluated code
685 ^^^^^^^^^^^^^^
686
687 When the compiler type checks the source code, :ref:`template-haskell` Splices
688 and :ref:`th-quasiquotation` will be replaced by the syntax tree fragments
689 generated from them. However for tools that operate on the source code the
690 code generator is usually more interesting than the generated code. For this
691 reason we included ``spliceRunAction``. This field is invoked on each expression
692 before they are evaluated. The input is type checked, so semantic information is
693 available for these syntax tree fragments. If you return a different expression
694 you can change the code that is generated.
695
696
697 ::
698
699     spliceRun :: [CommandLineOption] -> LHsExpr GhcTc -> TcM (LHsExpr GhcTc)
700
701
702 However take care that the generated definitions are still in the input of
703 ``typeCheckResultAction``. If your don't take care to filter the typechecked
704 input, the behavior of your tool might be inconsistent.
705
706 Interface files
707 ^^^^^^^^^^^^^^^
708
709 Sometimes when you are writing a tool, knowing the source code is not enough,
710 you also have to know details about the modules that you import. In this case we
711 suggest using the ``interfaceLoadAction``. This will be called each time when
712 the code of an already compiled module is loaded. It will be invoked for modules
713 from installed packages and even modules that are installed with GHC. It will
714 NOT be invoked with your own modules.
715
716 ::
717
718     interfaceLoad :: forall lcl . [CommandLineOption] -> ModIface
719                                     -> IfM lcl ModIface
720
721 In the ``ModIface`` datatype you can find lots of useful information, including
722 the exported definitions and type class instances.
723
724
725 Source plugin example
726 ^^^^^^^^^^^^^^^^^^^^^
727
728 In this example, we inspect all available details of the compiled source code.
729 We don't change any of the representation, but write out the details to the
730 standard output. The pretty printed representation of the parsed, renamed and
731 type checked syntax tree will be in the output as well as the evaluated splices
732 and quasi quotes. The name of the interfaces that are loaded will also be
733 displayed.
734
735 ::
736
737     module SourcePlugin where
738
739     import Control.Monad.IO.Class
740     import DynFlags (getDynFlags)
741     import Plugins
742     import HscTypes
743     import TcRnTypes
744     import HsExtension
745     import HsDecls
746     import HsExpr
747     import HsImpExp
748     import Avail
749     import Outputable
750     import HsDoc
751
752     plugin :: Plugin
753     plugin = defaultPlugin
754       { parsedResultAction = parsedPlugin
755       , renamedResultAction = renamedAction
756       , typeCheckResultAction = typecheckPlugin
757       , spliceRunAction = metaPlugin
758       , interfaceLoadAction = interfaceLoadPlugin
759       }
760
761     parsedPlugin :: [CommandLineOption] -> ModSummary -> HsParsedModule -> Hsc HsParsedModule
762     parsedPlugin _ _ pm
763       = do dflags <- getDynFlags
764            liftIO $ putStrLn $ "parsePlugin: \n" ++ (showSDoc dflags $ ppr $ hpm_module pm)
765            return pm
766
767     renamedAction :: [CommandLineOption] -> TcGblEnv -> HsGroup GhcRn -> TcM (TcGblEnv, HsGroup GhcRn)
768     renamedAction _ tc gr = do
769       dflags <- getDynFlags
770       liftIO $ putStrLn $ "typeCheckPlugin (rn): " ++ (showSDoc dflags $ ppr gr)
771       return (tc, gr)
772
773     typecheckPlugin :: [CommandLineOption] -> ModSummary -> TcGblEnv -> TcM TcGblEnv
774     typecheckPlugin _ _ tc
775       = do dflags <- getDynFlags
776            liftIO $ putStrLn $ "typeCheckPlugin (rn): \n" ++ (showSDoc dflags $ ppr $ tcg_rn_decls tc)
777            liftIO $ putStrLn $ "typeCheckPlugin (tc): \n" ++ (showSDoc dflags $ ppr $ tcg_binds tc)
778            return tc
779
780     metaPlugin :: [CommandLineOption] -> LHsExpr GhcTc -> TcM (LHsExpr GhcTc)
781     metaPlugin _ meta
782       = do dflags <- getDynFlags
783            liftIO $ putStrLn $ "meta: " ++ (showSDoc dflags $ ppr meta)
784            return meta
785
786     interfaceLoadPlugin :: [CommandLineOption] -> ModIface -> IfM lcl ModIface
787     interfaceLoadPlugin _ iface
788       = do dflags <- getDynFlags
789            liftIO $ putStrLn $ "interface loaded: " ++ (showSDoc dflags $ ppr $ mi_module iface)
790            return iface
791
792 When you compile a simple module that contains Template Haskell splice
793
794 ::
795
796     {-# OPTIONS_GHC -fplugin SourcePlugin #-}
797     {-# LANGUAGE TemplateHaskell #-}
798     module A where
799
800     a = ()
801
802 $(return [])
803
804 with the compiler flags ``-fplugin SourcePlugin`` it will give the following
805 output:
806
807 .. code-block:: none
808
809     parsePlugin:
810     module A where
811     a = ()
812     $(return [])
813     interface loaded: Prelude
814     interface loaded: GHC.Float
815     interface loaded: GHC.Base
816     interface loaded: Language.Haskell.TH.Lib.Internal
817     interface loaded: Language.Haskell.TH.Syntax
818     interface loaded: GHC.Types
819     meta: return []
820     interface loaded: GHC.Integer.Type
821     typeCheckPlugin (rn):
822     Just a = ()
823     typeCheckPlugin (tc):
824     {$trModule = Module (TrNameS "main"#) (TrNameS "A"#), a = ()}
825
826
827 .. _plugin_recompilation:
828
829 Controlling Recompilation
830 ~~~~~~~~~~~~~~~~~~~~~~~~~
831
832 By default, modules compiled with plugins are always recompiled even if the source file is
833 unchanged. This most conservative option is taken due to the ability of plugins
834 to perform arbitrary IO actions. In order to control the recompilation behaviour
835 you can modify the ``pluginRecompile`` field in ``Plugin``. ::
836
837     plugin :: Plugin
838     plugin = defaultPlugin {
839       installCoreToDos = install,
840       pluginRecompile = purePlugin
841       }
842
843 By inspecting the example ``plugin`` defined above, we can see that it is pure. This
844 means that if the two modules have the same fingerprint then the plugin
845 will always return the same result. Declaring a plugin as pure means that
846 the plugin will never cause a module to be recompiled.
847
848 In general, the ``pluginRecompile`` field has the following type::
849
850     pluginRecompile :: [CommandLineOption] -> IO PluginRecompile
851
852 The ``PluginRecompile`` data type is an enumeration determining how the plugin
853 should affect recompilation. ::
854     data PluginRecompile = ForceRecompile | NoForceRecompile | MaybeRecompile Fingerprint
855
856 A plugin which declares itself impure using ``ForceRecompile`` will always
857 trigger a recompilation of the current module. ``NoForceRecompile`` is used
858 for "pure" plugins which don't need to be rerun unless a module would ordinarily
859 be recompiled. ``MaybeRecompile`` computes a ``Fingerprint`` and if this ``Fingerprint``
860 is different to a previously computed ``Fingerprint`` for the plugin, then
861 we recompile the module.
862
863 As such, ``purePlugin`` is defined as a function which always returns ``NoForceRecompile``. ::
864
865   purePlugin :: [CommandLineOption] -> IO PluginRecompile
866   purePlugin _ = return NoForceRecompile
867
868 Users can use the same functions that GHC uses internally to compute fingerprints.
869 The `GHC.Fingerprint
870 <https://hackage.haskell.org/package/base-4.10.1.0/docs/GHC-Fingerprint.html>`_ module provides useful functions for constructing fingerprints. For example, combining
871 together ``fingerprintFingerprints`` and ``fingerprintString`` provides an easy to
872 to naively fingerprint the arguments to a plugin. ::
873
874     pluginFlagRecompile :: [CommandLineOption] -> IO PluginRecompile
875     pluginFlagRecompile =
876       return . MaybeRecompile . fingerprintFingerprints . map fingerprintString . sort
877
878 ``defaultPlugin`` defines ``pluginRecompile`` to be ``impurePlugin`` which
879 is the most conservative and backwards compatible option. ::
880
881     impurePlugin :: [CommandLineOption] -> IO PluginRecompile
882     impurePlugin _ = return ForceRecompile
883
884 .. _frontend_plugins:
885
886 Frontend plugins
887 ~~~~~~~~~~~~~~~~
888
889 A frontend plugin allows you to add new major modes to GHC.  You may prefer
890 this over a traditional program which calls the GHC API, as GHC manages a lot
891 of parsing flags and administrative nonsense which can be difficult to
892 manage manually.  To load a frontend plugin exported by ``Foo.FrontendPlugin``,
893 we just invoke GHC with the :ghc-flag:`--frontend ⟨module⟩` flag as follows:
894
895 .. code-block:: none
896
897     $ ghc --frontend Foo.FrontendPlugin ...other options...
898
899 Frontend plugins, like compiler plugins, are exported by registered plugins.
900 However, unlike compiler modules, frontend plugins are modules that export
901 at least a single identifier ``frontendPlugin`` of type
902 ``GhcPlugins.FrontendPlugin``.
903
904 ``FrontendPlugin`` exports a field ``frontend``, which is a function
905 ``[String] -> [(String, Maybe Phase)] -> Ghc ()``.  The first argument
906 is a list of extra flags passed to the frontend with ``-ffrontend-opt``;
907 the second argument is the list of arguments, usually source files
908 and module names to be compiled (the ``Phase`` indicates if an ``-x``
909 flag was set), and a frontend simply executes some operation in the
910 ``Ghc`` monad (which, among other things, has a ``Session``).
911
912 As a quick example, here is a frontend plugin that prints the arguments that
913 were passed to it, and then exits.
914
915 ::
916
917     module DoNothing.FrontendPlugin (frontendPlugin) where
918     import GhcPlugins
919
920     frontendPlugin :: FrontendPlugin
921     frontendPlugin = defaultFrontendPlugin {
922       frontend = doNothing
923       }
924
925     doNothing :: [String] -> [(String, Maybe Phase)] -> Ghc ()
926     doNothing flags args = do
927         liftIO $ print flags
928         liftIO $ print args
929
930 Provided you have compiled this plugin and registered it in a package,
931 you can just use it by specifying ``--frontend DoNothing.FrontendPlugin``
932 on the command line to GHC.