5.2 ast bump

[patricoferris]

This PR is a patch for an upcoming release of ppxlib where the internal AST is bumped from 4.14 to 5.2. Until that is merged and released, there is no reason to merge this PR.

To test these changes, you can use the following opam-based workflow. I've made releases of most of these patches to an opam-repository overlay.

opam switch create ppxlib-bump --repos=ppxlib=git+https://github.com/patricoferris/opam-repository#5.2-ast-bump
opam install <your-package>

The following describes the most notable changes to the AST.

Note: no update has been made of the opam file, but ppxlib will likely need a lower-bound before merging/releasing.

Functions

---

Currently

In the parsetree currently, functions like:

fun x y z -> ...

Are represented roughly as

Pexp_fun(x, Pexp_fun (y, Pexp_fun(z, ...)))

Functions like:

function A -> ... | B -> ...

Are represented roughly as

Pexp_function ([ case A; case B ])

Since 5.2

All of these functions now map to a single AST node Pexp_function (note, this is the same name as the old cases function). The first argument is a list of parameters meaning:

fun x y z -> ...

Now looks like:

Pexp_function([x; y; z], _constraint, body)

And the body is where we can either have more expressions (Pfunction_body _) or cases (Pfunction_cases _). That means:

function A -> ... | B -> ...

Has an empty list of parameters:

Pexp_function([], _, Pfunction_cases ([case A; case B]))

Local Module Opens for Types

Another feature added in 5.2 was the ability to locally open modules in type definitions.

module M = struct
  type t = A | B | C
end

type t = Local_open_coming of M.(t)

This has a Ptyp_open (module_identifier, core_type) AST node. Just like normal module opens this does create some syntactic ambiguity about where things come from inside the parentheses.

[Octachron]

As the derive_cor function is independent of the typing environment, I think it would be better to traverse the Ptyp_open _ node.

[patricoferris]

Indeed! Thanks @Octachron :)

[patricoferris]

Ah! We're actually going to have to hold off until ocaml-ppx/ppxlib#588

[kit-ty-kate]

any news on that?

[samoht]

@patricoferris is this ready to go now?

[patricoferris]

Still waiting for the PR I mentioned (being released as we speak ocaml/opam-repository#28610!)

[patricoferris]

I have updated this PR (and removed the ocamlformat change to make it easier to read).

We're in a bit of an annoying position where our (ppxlib) 0.37.0~5.4previewrelease does not have the changes in our 0.36.2 release. This should be fixed by our upcoming, full 0.37.0 release.

[kit-ty-kate]

@patricoferris would you be able to update the PR?

[kit-ty-kate]

ah nevermind it's ready but ocaml-ci hasn't updated with the full 0.37.0 release

[samoht]

@patricoferris -- do you mind rebasing the PR to pick up the latest releases?

[kit-ty-kate]

@samoht i believe the PR doesn't need rebasing. ocaml/opam-repository#28686 hasn't been merged yet actually

[patricoferris]

This, if the CI agrees, should be good to go. I have pushed three new commits to deal with the tests not working:

1. In 0193bb1 I switched the type constraints in the tests from let (_ : t) = ... to let _ : t = .... There is a quirk (maybe a bug) in ppxlib that the former syntax will not roundtrip on lower compiler versions. By using a syntax that will roundtrip on all compilers, the CI can stay running on more versions.
2. In 1ed4cf5 I disabled a warning on an unused type variable. This, since OCaml 5.4, was causing an error in the build.
3. The version of ocamlformat being used was 0.20.0 which reintroduced the syntax in (1) !! So I have bumped that to something newer and applied it in the last commit. Happy to carve that big change out into a separate PR, but I put it here for now as it was related to this bump in a way.

[patricoferris]

For extra clarification, the roundtripping is a known limitation in ppxlib: https://github.com/ocaml-ppx/ppxlib/blob/22778658345fce526e6146da188cdc2d6d2e5286/test/501_migrations/reverse_migrations.t#L142

It is not totally apparent to me just yet if that limitation should exist or not.