Prepare for 5.2 AST bump

[patricoferris]

Note, I couldn't quite work out the right change to make to the trace_ppx -- I think it is something close to this change but it is not quite right. Hopefully you will have more luck, do you use the overlay for testing your changes if you have time.

PR details

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.

[gares]

Looking at the code it looks OK, but you have reasons to suspect otherwise. What looks wrong to you?

That part of the ppx should elide function arguments carrying the trace attribute, as in fun x (y[@trace]) z -> to fun x z ->.
It seems you pay special care when the elided argument is the last one.

Anyway, maybe a simpler patch is to just filter the list of arguments the new AST features before doing a rec call? You kind of coalesce List.filter here, IMO.

Thanks for the patch.

[patricoferris]

That part of the ppx should elide function arguments carrying the trace attribute, as in fun x (y[@trace]) z -> to fun x z ->.
It seems you pay special care when the elided argument is the last one.

Ah okay! I've repushed filtering out the params that have the trace attribute. These seems to build ok (previously it didn't). Not quite sure when you would recurse into the body of the function though.

[kit-ty-kate]

are there any news on this?