Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Port to ppxlib #111

Closed
wants to merge 5 commits into from
Closed

Port to ppxlib #111

wants to merge 5 commits into from

Conversation

rgrinberg
Copy link
Contributor

@rgrinberg rgrinberg commented Nov 17, 2019

This is a counterpart to ocaml-ppx/ppx_deriving#206

  • Port to ppxlib
  • Remove cppo from tests
  • Remove ppx_tools.metaquot
  • Update opam file and constraints

let list = gen_def_loc Ast_builder.Default.elist
let pstr = gen_def_loc Ast_builder.Default.pstring
let plist = gen_def_loc Ast_builder.Default.plist
let lam = gen_def_loc Ast_builder.Default.pexp_fun Nolabel None
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@thierry-martinez there are some missing functions in your compatibility layer. However, I don't think it matters as much as we should probably just switch to ppxlib's Ast_builder API whenever possible

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If the interest is to help plugins migrate to the ppxlib layer as easily as possible (and that sounds good to me), then I would propose to integrate those definitions in Pppx_deriving.Ast_convenience indeed. It looks like this new Ast_convience was implemented by @thierry-martinez in a more low-level way (relying on Ast_helper rather than Ast_builder), your approach may actually also suggest sensible improvements to the implementation of current Ast_convenience definitions.

@XVilka
Copy link

XVilka commented Jan 8, 2020

Seems it can't find ppxlib still.

# (cd _build/default && /home/opam/.opam/4.07/bin/ocamlc.opt -w -40 -w -9 -g -bin-annot -I src/.ppx_deriving_yojson.objs/byte -I /home/opam/.opam/4.07/lib/ocaml-migrate-parsetree -I /home/opam/.opam/4.07/lib/ocaml/compiler-libs -I /home/opam/.opam/4.07/lib/ppx_derivers -I /home/opam/.opam/4.07/lib/ppx_deriving/api -I /home/opam/.opam/4.07/lib/ppx_tools -I /home/opam/.opam/4.07/lib/result -no-al[...]
# File "src/ppx_deriving_yojson.ml", line 1, characters 5-11:
# Error: Unbound module Ppxlib
-       ocamlc src/.ppx_deriving_yojson.objs/byte/ppx_deriving_yojson.{cmi,cmo,cmt} (exit 2)
- (cd _build/default && /home/opam/.opam/4.07/bin/ocamlc.opt -w -40 -w -9 -g -bin-annot -I src/.ppx_deriving_yojson.objs/byte -I /home/opam/.opam/4.07/lib/ocaml-migrate-parsetree -I /home/opam/.opam/4.07/lib/ocaml/compiler-libs -I /home/opam/.opam/4.07/lib/ppx_derivers -I /home/opam/.opam/4.07/lib/ppx_deriving/api -I /home/opam/.opam/4.07/lib/ppx_tools -I /home/opam/.opam/4.07/lib/result -no-alias-deps -o src/.ppx_deriving_yojson.objs/byte/ppx_deriving_yojson.cmo -c -impl src/ppx_deriving_yojson.pp.ml)
- File "src/ppx_deriving_yojson.ml", line 1, characters 5-11:
- Error: Unbound module Ppxlib

@XVilka
Copy link

XVilka commented May 6, 2020

Now that ppx_deriving was ported to ppxlib, it's time to revive this.
cc @rgrinberg @gasche @thierry-martinez

Ping me if I can help somehow.

@kit-ty-kate
Copy link
Collaborator

I agree. Since the next version of ppx_deriving uses ppxlib, this makes the OCaml 4.11 support PR (#118) obsolete and now this PR is required to get the 4.11 support

@kit-ty-kate kit-ty-kate mentioned this pull request May 6, 2020
Copy link
Contributor

@gasche gasche left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I had a look now (... sorry for the delay). The code looks nice overall, see a couple comments. Let me know if you don't have time to handle the stylistic comments yourself, in which case I could try to look at it.

@thierry-martinez : this PR contains proposal for extensions to your Ast_convenience reimplementation, which it would be nice to integrate upstream in Ppx_deriving. It also uses a different implementation style (using Ppxlib's Ast_builder) which could be an improvement to the current implementation. Could you let me know whether you (agree this would be a sensible idea and) would be available to integrate some of this in ppx_deriving in the coming week(s), or whether I should try to look at it?

We can still merge the current PR as-is if we want (maybe after some minor stylistic comments have been handled), and simplify the code later if Ppx_deriving.Ast_convenience gains the new combinators; we do not need a dependency on an upstream Ppx_deriving change.


open Ast_builder_default_loc

let warning_39 () =
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think it could be clearer if this was named disable_warning_39.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done in 84a0c33

let list = gen_def_loc Ast_builder.Default.elist
let pstr = gen_def_loc Ast_builder.Default.pstring
let plist = gen_def_loc Ast_builder.Default.plist
let lam = gen_def_loc Ast_builder.Default.pexp_fun Nolabel None
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If the interest is to help plugins migrate to the ppxlib layer as easily as possible (and that sounds good to me), then I would propose to integrate those definitions in Pppx_deriving.Ast_convenience indeed. It looks like this new Ast_convience was implemented by @thierry-martinez in a more low-level way (relying on Ast_helper rather than Ast_builder), your approach may actually also suggest sensible improvements to the implementation of current Ast_convenience definitions.

@@ -492,7 +468,7 @@ let ser_str_of_type_ext ~options ~path:_ ({ ptyext_path = { loc }} as type_ext)
Ppx_deriving.mangle_lid
(`PrefixSuffix ("M", "to_yojson")) type_ext.ptyext_path.txt
in
String.concat "." (Longident.flatten mod_lid)
String.concat "." (Longident.flatten_exn mod_lid)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The whole line could be written Longident.name mod_lid instead.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done in 5a26808

@@ -704,7 +680,7 @@ let desu_str_of_type_ext ~options ~path ({ ptyext_path = { loc } } as type_ext)
Ppx_deriving.mangle_lid
(`PrefixSuffix ("M", "of_yojson")) type_ext.ptyext_path.txt
in
String.concat "." (Longident.flatten mod_lid)
String.concat "." (Longident.flatten_exn mod_lid)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

(Here again Longident.name would be nice.)

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done in 5a26808

@XVilka
Copy link

XVilka commented May 9, 2020

I would suggest waiting until also ppx_deriving_protobuf is ported, then we can see if some helpers need to be moved to ppx_deriving itself, and removed from here and ppx_deriving_protobuf.

@XVilka
Copy link

XVilka commented May 9, 2020

@gasche also please look at the #118 - it superseded this PR

thierry-martinez added a commit to thierry-martinez/ppx_deriving_yojson that referenced this pull request May 21, 2020
thierry-martinez added a commit to thierry-martinez/ppx_deriving_yojson that referenced this pull request May 21, 2020
@thierry-martinez
Copy link
Contributor

I opened a new PR #121 to include @gasche's suggestions and @kit-ty-kate's #118 work for OCaml 4.11 as well.

gasche added a commit that referenced this pull request May 24, 2020
Port to ppxlib and OCaml 4.11 (continuation of #111 and #118)
@gasche
Copy link
Contributor

gasche commented May 24, 2020

This is superseded by #121 which I just merged. Thanks a lot, and sorry for the lack of reactivity.

@gasche gasche closed this May 24, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants