Upgrade to ppxlib 0.16.0

[kit-ty-kate]

This PR simply rebases #231 on top of master.
Here is the diff with the latest commit of #231 (d51cdbd):

$ git diff d51cdbd
diff --git a/CHANGELOG.md b/CHANGELOG.md
index 7a48b83..310318d 100644
--- a/CHANGELOG.md
+++ b/CHANGELOG.md
@@ -1,12 +1,41 @@
-Changelog
-=========
+5.1 (26/10/2020)
+----------------
 
-Future version (4.5)
---------------------
+* Update to ppxlib 0.15.0 #235
+  (Kate Deplaix)
+
+5.0 (26/10/2020)
+----------------
 
 * Migrate to ppxlib #206, #210
   (Anton Kochkov, Gabriel Scherer, Thierry Martinez)
 
+4.5
+---
+
+* Add support for OCaml 4.11.
+  - `Ppx_deriving.string_of_{constant,expression}_opt` to destruct
+    `Pconst_string` in a version-independent way
+  #220, #222
+  (Kate Deplaix, Thierry Martinez, review by Gabriel Scherer)
+
+* Stronger type equalities in `Ppx_deriving_runtime` (for instance,
+  `Ppx_deriving_runtime.result` and `Result.result` are now compatible with
+  all OCaml versions)
+  #223, #225
+  (Thierry Martinez, review by Gabriel Scherer)
+
+* `Ppx_deriving_runtime.Option` compatibility module
+  #222
+  (Thierry Martinez, review by Gabriel Scherer)
+
+4.4.1
+-----
+
+* Add support for OCaml 4.10
+  #211
+  (Kate Deplaix, review by Gabriel Scherer)
+
 4.4
 ---
 
diff --git a/src/api/ppx_deriving.cppo.mli b/src/api/ppx_deriving.cppo.mli
index 8599c84..81cb5b3 100644
--- a/src/api/ppx_deriving.cppo.mli
+++ b/src/api/ppx_deriving.cppo.mli
@@ -79,6 +79,8 @@ val lookup : string -> deriver option
 val raise_errorf : ?sub:Ocaml_common.Location.error list ->
                    ?loc:Location.t -> ('a, unit, string, 'b) format4 -> 'a
 
+(** {2 Coercions} *)
+
 (** [string_of_core_type typ] unparses [typ], omitting any attributes. *)
 val string_of_core_type : Parsetree.core_type -> string
 

I'm not sure where I got the (** {2 Coercions} *) bit back from but it seems to have been deleted on master, however it seems to make more sense to have it so I readded it.

[kit-ty-kate]

CI is green.

[kit-ty-kate]

Sounds like I was a little to overexcited for this. I should've done more testing...

@NathanReb any idea what's wrong in this PR? The change gave me a slew of revdeps failures here: https://ci.ocaml.org/ocaml/opam-repository/pr/17539?test=2%20Revdeps

Most of them use ocamlfind instead of dune (that's why I couldn't detect this in the tests) and fail in a similar manner:

#=== ERROR while compiling webidl.1.4 =========================================#
# context              2.0.7 | linux/x86_64 | ocaml-base-compiler.4.11.1 | file:///home/opam/opam-repository
# path                 ~/.opam/4.11/.opam-switch/build/webidl.1.4
# command              ~/.opam/4.11/bin/ocaml setup.ml build
# exit-code            10
# env-file             ~/.opam/log/webidl-25-e1f60c.env
# output-file          ~/.opam/log/webidl-25-e1f60c.out
### output ###
# + ocamlfind ocamldep -package ppx_deriving.show -modules src/syntax/ast.ml > src/syntax/ast.ml.depends
# File "src/syntax/ast.ml", line 1:
# Error: External preprocessor does not produce a valid file
# Command line: /home/opam/.opam/4.11/lib/ppx_deriving/./ppx_deriving package:ppx_deriving.show '/tmp/camlppx5490e0' '/tmp/camlppx84ce80'

There is also a more annoying one here:

#=== ERROR while compiling satyrographos.0.0.2.7 ==============================#
# context              2.0.7 | linux/x86_64 | ocaml-base-compiler.4.11.1 | file:///home/opam/opam-repository
# path                 ~/.opam/4.11/.opam-switch/build/satyrographos.0.0.2.7
# command              ~/.opam/4.11/bin/dune build -p satyrographos -j 72
# exit-code            1
# env-file             ~/.opam/log/satyrographos-25-7e9aa9.env
# output-file          ~/.opam/log/satyrographos-25-7e9aa9.out
### output ###
#     ocamldep src/.satyrographos.objs/buildScript.ml.d (exit 2)
# (cd _build/default && /home/opam/.opam/4.11/bin/ocamldep.opt -modules -ppx '.ppx/b4175a47579235f9b841d5d1f64bf609/ppx.exe --as-ppx --cookie '\''library-name="satyrographos"'\''' -impl src/buildScript.ml) > _build/default/src/.satyrographos.objs/buildScript.ml.d
# Fatal error: exception (Failure
#   "At most one preprocessor is allowed, while got: <preprocess:ppx_deriving>, <preprocess:optcomp>")
# Raised at Ast_mapper.extension_of_exn in file "parsing/ast_mapper.ml", line 941, characters 12-21
# Called from Ast_mapper.apply_lazy.implem in file "parsing/ast_mapper.ml", line 959, characters 38-58
# Called from Ast_mapper.apply_lazy.rewrite in file "parsing/ast_mapper.ml", line 996, characters 14-27
# Called from Ppxlib__Driver.standalone in file "src/driver.ml", line 1247, characters 6-39
# Re-raised at Location.report_exception.loop in file "parsing/location.ml", line 926, characters 14-25
# Called from Ppxlib__Driver.standalone in file "src/driver.ml", line 1252, characters 4-59
# Called from _ppx in file ".ppx/b4175a47579235f9b841d5d1f64bf609/_ppx.ml", line 1, characters 9-36
# File "src/buildScript.ml", line 1:
# Error: Error while running external preprocessor
# Command line: .ppx/b4175a47579235f9b841d5d1f64bf609/ppx.exe --as-ppx --cookie 'library-name="satyrographos"' '/tmp/camlppx18aaf6' '/tmp/camlppxd5f4f9'

[NathanReb]

preprocess_intf and preprocess_impl are special fields used to define a transformation that must run before anything else and as it turns out you can only use one such ppx at any given time, this is why it's incompatible with ppx_optcomp. I'm guessing this is required because ppxlib otherwise throws warnings about uninterpreted deriving plugins right?

[NathanReb]

I'd have to take a deeper look but to be honest I wouldn't put too much effort into this, the plan is to migrate ppx_deriving plugins to pure ppxlib ones. The kind of issues described above is exactly the reason why we shouldn't use ppx_deriving anymore.

If users feel like ppxlib lacks some important ppx_deriving features, I'd be happy to hear about them. We already started importing features to ppxlib to make the migration easier.

[gasche]

Who is going to work on migrating all ppx_deriving plugins to pure ppxlib plugins? The work here (which is a continuation of the work by @thierry-martinez) is precisely trying to start such a migration effort, and yet you seem to suggest that it's not the right way to proceed. If someone is volunteering to implement the remaining ppx_deriving plugins in ppxlib directly, I'm happy to see it done, but until it happens we would welcome your help ensuring that the migration to ppxlib is smooth enough (as was suggested in the past).

[NathanReb]

In the meantime we can start by adding a conflict with ppx_optcomp and any other such ppx-es registering preprocess_x transformation.

I'll look into the other failure.

@gasche I'm not saying it's not the right way to proceed, just that it comes with some limitations. I'm not sure the cost of overcoming those in ppxlib is smaller than the cost of migrating the few widely used plugins. I'm also not sure it's worth the maintenance cost it will have on ppxlib in the long run.

A good intermediate step would be to try to partially rewrite ppx_deriving so that it registers its plugins using Ppxlib.Deriving API rather than defining its own whole AST transformation. That would improve the compatibility with other ppxlib plugins a lot and would solve the conflict with ppx_optcomp. If you're willing to work on this I'd be happy to help and answer any questions you might have.

[NathanReb]

I think clearing out this file is responsible for breaking compat with ocamlbuild!

CC @jeremiedimino @kit-ty-kate @thierry-martinez