While working on a new backend for OCaml to generate Erlang sources, I
found the need to read the .cmi file back into a `Types.signature`
value.
@Drup spotted that I was reading the file and pointed out this value was
already being read during the type checking process.
A quick check at the `Typedtree.module_coercion` showed us that it would
be difficul to extract the same information that is readily available in
the signature value.
This change will expose the signature value directly, so other backends
relying on this signature information do not need to do the extra work
of reading it again.
I think this clarifies the fact that the `info` value is a resource that
has a limited lifetime. The new API lets us create (and close) the ppf_dump
directly from `Compile_common.with_info`, simplifying the API for user.
The previous label name made little sense to me, and in fact
I thought it meant that the boolean indicates whether the path should
be initialized or not.
wrap_compilation makes the compilation pipeline non-modular by
exposing a split between two fixed passes, a frontend and a backend,
in a .mli interface. I need a finer-grained interface for a feature
I've been using in my Menhir-parser branch, and it is likely that
other users also will need to be finer-grained than that.
This PR pushes the error/ressource handling contained with
wrap_compilation into its producers (note: this change assume that
only typecheck_impl needs Stypes.dump, and that only the optcompile
backend may generate `obj` and `cmx` files), so that the logic in
"wrap" becomes very simple, and then inlines it in the two users in
{opt,}compile.ml.
Leandro Ostera
Gabriel Scherer
Valentin Gatien-Baron
Drup