OCaml 5.4 support

[kit-ty-kate]

ppx_import currently fails to build with OCaml 5.4:

#=== ERROR while compiling ppx_import.1.11.0 ==================================#
# context              2.4.0~rc1 | linux/x86_64 | ocaml-base-compiler.5.4.0~alpha1 | file:///home/opam/opam-repository
# path                 ~/.opam/5.4/.opam-switch/build/ppx_import.1.11.0
# command              ~/.opam/5.4/bin/dune build -p ppx_import -j 1
# exit-code            1
# env-file             ~/.opam/log/ppx_import-14-42a25b.env
# output-file          ~/.opam/log/ppx_import-14-42a25b.out
### output ###
# (cd _build/default && /home/opam/.opam/5.4/bin/ocamlc.opt -w -40 -g -bin-annot -bin-annot-occurrences -I src/.ppx_import.objs/byte -I /home/opam/.opam/5.4/lib/ocaml-compiler-libs/common -I /home/opam/.opam/5.4/lib/ocaml-compiler-libs/shadow -I /home/opam/.opam/5.4/lib/ocaml/compiler-libs -I /home/opam/.opam/5.4/lib/ppx_derivers -I /home/opam/.opam/5.4/lib/ppxlib -I /home/opam/.opam/5.4/lib/ppxlib/ast -I /home/opam/.opam/5.4/lib/ppxlib/astlib -I /home/opam/.opam/5.4/lib/ppxlib/print_diff -I /home/opam/.opam/5.4/lib/ppxlib/stdppx -I /home/opam/.opam/5.4/lib/ppxlib/traverse_builtins -I /home/opam/.opam/5.4/lib/sexplib0 -I /home/opam/.opam/5.4/lib/stdlib-shims -no-alias-deps -open Ppx_import__ -o src/.ppx_import.objs/byte/ppx_import.cmo -c -impl src/ppx_import.pp.ml)
# File "src/ppx_import.ml", line 34, characters 40-43:
# 34 |     | Longident.Ldot (lid, id) -> print lid ("." :: id :: acc)
#                                              ^^^
# Error: The value lid has type Longident.t Location.loc
#        but an expression was expected of type Longident.t

[kit-ty-kate]

The release of OCaml 5.4.0 is currently planned for Thursday

[gasche]

@kit-ty-kate I tried to look at this. The issue comes from the fact that Longident changed upstream, and the ppx_import codebase uses a mix of Astlib.Longident and (compiler-libs') Longident, which are not compatible anymore; there is no easy way to get rid of compiler-libs Longident, because we use functions from the Env module that are not covered by Ppxlib.

Would you by chance know of other projects having encountered the same issue, and could you point me at how they fixed it?

[kit-ty-kate]

@gasche things like janestreet/ppxlib_jane#7 and ocaml-ppx/ppx_deriving#296 are the closest i have, but these weren't as tangled between ppxlib functions and compiler-libs functions like ppx_import is.

cc @patricoferris @NathanReb do you have any idea?

[NathanReb]

I'll take a look at this to see how we can make it work!

[NathanReb]

Ok so from what I gather the problem is that ppx_import will now need to handle Longidents pre and post 5.4 so it needs a compat layer anyway since it interacts with the typechecker.

We do not expose copy_longident (along with a few other that ppx_import re-implemented). Would exposing this be enough for ppx_import?

[kit-ty-kate]

I don't know. There are other compiler-libs API changes and i don't currently have time to look at it in greater details

[gasche]

It looks like @Octachron just did this in #100.

[NathanReb]

I exposed Astlib.Longident.to/from_compiler in ppxlib.0.37.0 which you should be able to use if you'd like!

[gasche]

I went ahead and merged #100 to unblock (the CI and) 5.4 users. We can move to Astlib compat functions in a second step.

I dislike doing releases, and would be happy to let anyone else (@NathanReb, @kit-ty-kate?) take care of it. Would there by chance be a volunteer?

[kit-ty-kate]

I could try to backport on the v1.x branch and do a release of that if you want. I don't know enough about ppx_import to feel confident about releasing the 2.0 work though.

[Octachron]

I tend to agree that it would be better to release a version of ppx_import which supports both the old syntax and OCaml 5.4 .

Speaking about the 2.0 syntax, maybe it would make sense to have a separate ppx_import2 opam package? I have the impression that we are in the rare case where mixing the two versions in the same cone of dependency is fine.

[ejgallego]

Hi folks, I did sync with Gabriel offline and will do a release for 5.4 using the 1.x branch.

Indeed, it'd be great to release some package using the 2.0 syntax at some point. There are not some many revdeps, so IMHO maybe we could just bump the version and have users update.