On this branch, we provide a Ppxlib version, which can be compiled with
OCaml's trunk
branch. Whenever you want to compile a project that
(transitively) depends on PPXs with trunk
, please pin Ppxlib to
this branch.
The branch is maintained manually. So each time the compiler adds a new
syntax feature, first we need to bring this branch back in sync with
trunk
and then you'll need to re-pin your Ppxlib. Please, open an
issue or a PR, if this branch doesn't compile with trunk
. Also open
an issue, if there's a feature/bug-fix on Ppxlib's main
branch that
you'd like to have here, so that we rebase.
Ppxlib supporting trunk
can be interpreted in two different ways.
One notion of trunk
-support is that a project depending on Ppxlib can
be compiled with trunk
under the assumption that the project
doesn't use the new syntax features in trunk
. That's what this branch
provides.
The other notion of trunk
-support should actually be called
trunk
-feature support: you can use the new trunk
syntax features
in a project which depends on Ppxlib and that you compile with trunk
.
It's not unlikely that you'll get a Ppxlib runtime error (i.e. project
compile time error), if you try to use this branch in that situation.
The Ppxlib behavior in the situation of trunk
support is: The parsetree
version exposed by Ppxlib is still the one from the latest stable compiler
and all PPXs are defined against that one. However, Ppxlib has hold of
trunk
's parsetree version and knows how to migrate between that
parsetree version and the parsetree version of the latest stable compiler.
You can find those parsetrees and parsertree migration modules in Ppxlib's
Astlib
library. So, when compiling a file with trunk
, the Ppxlib driver
will parse the file into the trunk
parsetree, migrate down to the latest
stable parsetree, do the PPX expansions and migrate back to trunk
's
parsetree. The downward migration will error, if the parsetree contains a
feature that isn't well-defined in the latest stable parsetree version.
The behavior in the case of trunk
-feature support would be different.
In that case, Ppxlib would have to expose the trunk
parsetree, so that
the PPXs would be defined against that one. So, Ppxlib would have to bump
its internal parsetree to the trunk
parsetree. Bumping the Ppxlib parsetree
always means potentially breaking PPXs. When bumping the Ppxlib parsetree
to the parsetree of an about-to-be-released stable compiler version, we
create a work-space with all opam PPXs and send patch PRs to the ones we
break. However, for trunk
we wouldn't do such an effort.