Module Ppxlib.Driver

Interaction with the driver, such as getting/seeting cookies, adding arguments.

The relevant part in the manual is the section on its execution.

val add_arg : Stdlib.Arg.key -> Stdlib.Arg.spec -> doc:string -> unit

Add one argument to the command line

module Lint_error : sig ... end

Error reported by linters

module Cookies : sig ... end
module Instrument : sig ... end

register_transformation name registers a code transformation.

name is a logical name for the set of transformations (such as sexp_conv or bin_prot). It is mostly used for debugging purposes.

rules is a list of context independent rewriting rules, such as extension point expanders. This is what most code transformation should use.

extensions is a special cases of rules and is deprecated. It is only kept for backward compatibility.

enclose_impl and enclose_intf produces a header and footer for implementation/interface files. They are a special case of impl and intf. The header is placed after any initial module-level attributes; the footer is placed after everything else. Both functions receive a location that denotes all of the items between header and footer, or None if the that list of items is empty.

impl is an optional function that is applied on implementation files and intf is an optional function that is applied on interface files. These two functions are applied on the AST of the whole file. They should only be used when the other mechanism are not enough. For instance if the transformation expands extension points that depend on the context.

lint_impl and lint_intf are applied to the unprocessed source. Errors they return will be reported to the user as preprocessor warnings.

instrument can be used to instrument implementation files. Its transformation is applied to the AST of the whole file. The difference to impl is that you can specify if it should be applied before or after all rewriters defined through rules, impl or intf are applied.

More information on each phase, and their relative order, can be found in the manual.

Same as register_transformation except that it uses the same AST as the current ocaml compiler.

This is not the intended way of using driver. This is only for ppx rewriters that are not written using ppxlib but want to export a driver compatible library.

val register_code_transformation : name:string -> ?aliases:string list -> impl: (Astlib.Ast_500.Parsetree.structure_item list -> Astlib.Ast_500.Parsetree.structure_item list) -> intf: (Astlib.Ast_500.Parsetree.signature_item list -> Astlib.Ast_500.Parsetree.signature_item list) -> unit

Same as:

register_transformation ~name ~impl ~intf ()
  • deprecated [since 2015-11] use register_transformation instead
val register_correction : loc:Location.t -> repl:string -> unit

Rewriters might call this function to suggest a correction to the code source. When they do this, the driver will generate a file.ml.ppx-corrected file with the suggested replacement. The build system will then show the diff to the user who is free to accept the correction or not.

val register_process_file_hook : (unit -> unit) -> unit

Hook called before processing a file

module V2 : sig ... end
module Create_file_property (Name : sig ... end) (T : Stdppx.Sexpable.S) : sig ... end

Create a new file property.

val standalone : unit -> unit

Suitable for -pp and also usable as a standalone command line tool.

If the first command line argument is -as-ppx then it will run as a ppx rewriter.

val run_as_ppx_rewriter : unit -> unit

Suitable for -ppx. Used only for the public release.

val pretty : unit -> bool

If true, code transformations should avoid generating code that is not strictly necessary, such as extra type annotations.