-
Notifications
You must be signed in to change notification settings - Fork 29
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
Ppxlib.0.26.0 compatibility #69
Ppxlib.0.26.0 compatibility #69
Conversation
@@ -288,6 +288,7 @@ let ptype_decl_of_ttype_decl ~manifest ~subst ptype_name | |||
in | |||
{ pcd_name = | |||
{txt = Ocaml_common.Ident.name cd.cd_id; loc = cd.cd_loc} | |||
; pcd_vars = [] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would expect ; pcd_vars = cd.cd_vars
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hi @gasche, thanks for reviewing! The reason why I've made it an empty list is that in these patch PRs I simply preserve the behavior from before the AST bump. Sounds good to already implement the good new behavior though.
So it's a good point that here the good new behavior would probably be to use cd.cd_vars
! The problem is that cd
comes from the Types
module, in which no vars
field has been added to constructor_declaration
. Btw, I was already wondering why no vars
field has been added to Types.constructor_declaration
. Do you know why (might be an obvious question)?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actually I don't know; I thought that this came from Typedtree.constructor_declaration
, and that one has a cd_vars
as expected. I'll ask on the original PR.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for the PR! CI seems unhappy tho, any idea @pitag-ha ?
Would you mind updating the CHANGES.md
file too?
For the CI to run, we'll probably have to wait for the patch PR on |
Version 0.15.1 of |
I tried re-running the CI , but it seems 4.05-4.09 don't find a suitable opam setup. @pitag-ha , what's the next step here? |
I forced a minimum version of
So my understanding is that to support |
I don't indeed see a way out of this problem, seems to me that base bump on the minimal OCaml version is quite restrictive. |
Well, one way to maybe make this work is only to run the test suite in OCaml 4.10 and onwards, that works, I've checked, but maybe a bit risky in terms of testing. |
The current Debian Stable, released in August 2021, has OCaml 4.11. So maybe requiring 4.10 is okay? If it's not, I guess you need to discuss with ppxlib maintainers to see if they could support older releases. |
Thanks for having a look at this, @tatchi!
@gasche , what are you referring to? Ppxlib supports all compiler versions from 4.04.1 on. Do you mean to see if ppxlib can stay compatible with older versions of ppx_sexp_conv? If so: I could see if the ppx_sexp_comv maintainers (i.e. Jane street) would be willing to also merge and release my patch PR on top of their 0.14 branch. |
I misunderstood from the above that ppxlib somehow creates the dependency on a recent base. In fact we (ppx_import) depend on ppx_sexp_conv for a test where we import a type to do |
I'm fine disabling the test in < 4.10 , it is not so complex, just tweak the CI file and add a new target to the test makefile (I'll be happy to help if that's an issue) |
We need to tweak the opam file too as to install the stuff condictionally on the OCaml version. |
Great @pitag-ha , it seems to work, thanks! I will prepare a new release. Would you like to squash the last commits so history is a bit cleaner? |
fa9bc3b
to
4ee94ea
Compare
Perfect, thank you!
Sure, I've just done that. |
Or did you want me to sqash more commits? |
As you prefer, IMO it makes sense that commits are structured in such a way that a particular checkout is consistent, so indeed, after a review I think it makes sense to squash them all. For example the first commit only would not pass CI, the second would miss a change, etc... By the way, was @gasche question above resolved? |
This commit makes the ppx compatible with ppxlib.0.25.0. Disable the sexp tests on old compilers Due to its ppxlib constraint, ppx_import needs ppx_sexp_conv >= v.0.15.0, which (transitively via base) requires a compiler >= 4.10.0.
4ee94ea
to
838084a
Compare
Yes, I agree. I've done that now.
@gasche's proposal above is still being blocked by the fact that the compiler |
Thanks a lot, I think the plan looks good! |
CHANGES: * Update ppxlib to 0.26.0 (ocaml-ppx#69, @pitag-ha)
CHANGES: * Update ppxlib to 0.26.0 (ocaml-ppx/ppx_import#69, @pitag-ha)
Just to come back to the last question that was still kind of open: as pointed out here, explicit binders of type variables don't have any impact on the semantics of the program (and, btw, they don't even have an impact on the error reporting). So it does seem like it's ok for |
This is a patch PR to make the PPX compatible with ppxlib.0.26.0 which has bumped the AST to 4.14/5.00.