`val add_arg : Caml.Arg.key ‑> Caml.Arg.spec ‑> doc:Ppxlib__.Import.string ‑> Ppxlib__.Import.unit`

Add one argument to the command line

`module Lint_error : sig ... end`

Error reported by linters

`module Cookies : sig ... end`
`val register_transformation : ?⁠extensions:Extension.t Ppxlib__.Import.list ‑> ?⁠rules:Context_free.Rule.t Ppxlib__.Import.list ‑> ?⁠enclose_impl:(Location.t Ppxlib__.Import.option ‑> Ppxlib__.Import.structure * Ppxlib__.Import.structure) ‑> ?⁠enclose_intf:(Location.t Ppxlib__.Import.option ‑> Ppxlib__.Import.signature * Ppxlib__.Import.signature) ‑> ?⁠impl:(Ppxlib__.Import.structure ‑> Ppxlib__.Import.structure) ‑> ?⁠intf:(Ppxlib__.Import.signature ‑> Ppxlib__.Import.signature) ‑> ?⁠lint_impl:(Ppxlib__.Import.structure ‑> Lint_error.t Ppxlib__.Import.list) ‑> ?⁠lint_intf:(Ppxlib__.Import.signature ‑> Lint_error.t Ppxlib__.Import.list) ‑> ?⁠preprocess_impl:(Ppxlib__.Import.structure ‑> Ppxlib__.Import.structure) ‑> ?⁠preprocess_intf:(Ppxlib__.Import.signature ‑> Ppxlib__.Import.signature) ‑> Ppxlib__.Import.string ‑> Ppxlib__.Import.unit`

`register_transformation name` registers a code transformation.

`name` is a logical name for the transformation (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. Rules from all registered transformations are all applied at the same time, before any other transformations. Moreover they are applied in a top-down manner, giving more control to extensions on how they interpret their payload.

For instance:

- some extensions capture a pretty-print of the payload in their expansion and using top-down ensures that the payload is as close as possible to the original code
- some extensions process other extension in a special way inside their payload. For instance `%here` (from ppx_here) will normally expand to a record of type `Lexing.position`. However when used inside `%sexp` (from ppx_sexp_value) it will expand to the human-readable sexp representation of a source code position.

`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`. Both functions receive a location that denotes the whole file, or `None` if the file contains nothing.

`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.

If no rewriter is using `impl` and `intf`, then the whole transformation is completely independent of the order in which the various rewriter are specified. Moreover the resulting driver will be faster as it will do only one pass (excluding safety checks) on the whole AST.

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

`preprocess_impl` and `preprocess_intf` are applied after linters, but before other transformations.

`val register_transformation_using_ocaml_current_ast : ?⁠impl:(Migrate_parsetree.OCaml_current.Ast.Parsetree.structure ‑> Migrate_parsetree.OCaml_current.Ast.Parsetree.structure) ‑> ?⁠intf:(Migrate_parsetree.OCaml_current.Ast.Parsetree.signature ‑> Migrate_parsetree.OCaml_current.Ast.Parsetree.signature) ‑> Ppxlib__.Import.string ‑> Ppxlib__.Import.unit`

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:Ppxlib__.Import.string ‑> impl:(Ppxlib__.Import.structure ‑> Ppxlib__.Import.structure) ‑> intf:(Ppxlib__.Import.signature ‑> Ppxlib__.Import.signature) ‑> Ppxlib__.Import.unit`

Same as:

          register_transformation
            ~name
            ~impl
            ~intf
            ()

- Deprecated [since 2015-11] use register_transformation instead

`val register_correction : loc:Location.t ‑> repl:Ppxlib__.Import.string ‑> Ppxlib__.Import.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 : (Ppxlib__.Import.unit ‑> Ppxlib__.Import.unit) ‑> Ppxlib__.Import.unit`

Hook called before processing a file

`module Create_file_property : functor (Name : sig ... end) -> functor (T : Ppxlib__.Import.Sexpable.S) -> sig ... end`

Create a new file property.

`val standalone : Ppxlib__.Import.unit ‑> Ppxlib__.Import.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 : Ppxlib__.Import.unit ‑> Ppxlib__.Import.unit`

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

`val pretty : Ppxlib__.Import.unit ‑> Ppxlib__.Import.bool`

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