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