Add support for OCaml 5.4.0

[shym]

This PR adds support for OCaml 5.4.0.

The patches for the compiler are in plain text, so as to be compatible with whatever choice we go with, regarding our patch tool (cf #151, #154). Anyway, we are down to 3 patches, 2 of which will be in 5.5.

The third patch is there to set the limit to 1 domain (in particular to avoid allocating memory for 128 domains). I think a patch might still be the best way to change that behaviour of the compiler in the versions to come (the commit message of that patch explains an alternative, exploiting OCAMLRUNPARAM’s d parameter, but that would require some kind of sscanf in nolibc).

Small note: the example outputting Sys.unix now properly returns false, as it should, with OCaml 5.4.0 (as part of the cross-compilation patches in OCaml 5.4.0).

[hannesm]

Should we really keep 5.3.0 support when 5.4.0 is available? If yes, why? I read that there are very good changes in 5.4.

[hannesm]

also, Mirage CI: can we get a 5.4 builder?

[dinosaure]

Small note: the example outputting Sys.unix now properly returns false, as it should, with OCaml 5.4.0 (as part of the cross-compilation patches in OCaml 5.4.0).

I hope that ocaml-solo5 still produces the same *.cmi (and its signatures) than the OCaml compiler. I will do some tests about that (and probably complete the GitHub action also).

[shym]

Should we really keep 5.3.0 support when 5.4.0 is available? If yes, why?

It’s more that I didn’t see any compelling reasons to break support for 5.3.0 (and not everything might be compatible with 5.4.0 yet). It could make it easier to run benchmarks with the two compilers, if that’s useful. Even if I know many more GC improvements are only in the pipeline and not yet in 5.4.

I read that there are very good changes in 5.4.

Indeed.

[shym]

I hope that ocaml-solo5 still produces the same *.cmi (and its signatures) than the OCaml compiler. I will do some tests about that

The patches left now really only enable freestanding targets, so I don’t expect they could have any impact there. So if there are differences, we’ll have a better chance of tracking their origin (some compiler configure-time options come to mind).

[Firobe]

also, Mirage CI: can we get a 5.4 builder?

Should be the case as soon as ocurrent/mirage-ci#53 is merged

[Firobe]

Hi, is there further work needed to merge 5.4 support?

[shym]

Hi, is there further work needed to merge 5.4 support?

Not that I think of, on my end at least. (Maybe it would be good to schedule a new run after a merge of #154, just to be sure, if #154 is to be integrated before a new release?)

[dinosaure]

I can confirm that stdlib.cmi is the same as the host compiler, for me, it's good to merge.

[shym]

I just applied Hannes’ suggestions on the version constraints and rebased.

[shym]

@dinosaure: we should really use git push --force-with-lease, if a force is really needed, when working concurrently on a branch: you overwrote the cleanups and fixes I had made.

[shym]

I’ve merged the conflicting changes, this is now ready, I think.

[dinosaure]

Seesm perfect for me.

[hannesm]

Great. I'll take the opportunity to merge and cut a release. Thanks to everybody involved.