WIP: Improve deriving inline so it can be used alongside other ppx-es

[NathanReb]

No description provided.

[NathanReb]

CC @mbarbin you should be able to try this out for your usecase, simply add the -no-corrections to your (preprocess (pps ...)) field and it will not require that you add the ppx-es you only use with deriving_inline and won't generate corrections during builds anymore.

This is still WIP as I'm trying to tie all loose ends but it should already be usable for common use cases.

[mbarbin]

Hi @NathanReb I wanted to let you know that it will take me a bit of time to get back to you on this, but I am excited to try it out as soon as I get a chance. Thank you for your work on this!

[mbarbin]

@NathanReb I tried it in this PR => mbarbin/vcs#32 and commented there directly. To summarize what I got:

• ✅ The build works
• ✅ The doesn't round-trip errors are gone
• ❌ The lint current fails with small auto-formatting issues

So, this is definitely a lot of progress, and possibly very close to working! Thanks a lot.

[NathanReb]

@mbarbin is this something you are still interested in?

[mbarbin]

@mbarbin is this something you are still interested in?

Hi @NathanReb thanks for asking! Yes absolutely. I didn't want to be a distraction from all the amazing work you guys did for OCaml 5.2 ast migration, and the support for effect syntax (which I tried with 0.35, and it worked very nicely), but sure this is something I'd be very keen on seeing progressing in the long run.

I did a little pass over this and summarize below the tickets which I think are linked to this scope of work. Please let me know if you agree, and if I have forgotten something:

ocaml/dune#2992
mbarbin/vcs#32
#342
#338

Thank you!

[NathanReb]

Great to hear, I'll resume working on this!

[mbarbin]

Dear ppxlib devs,

I wanted to ping some folks about that work. Do you think it would be possible to resume some work on deriving_inline to make it usable in more contexts? I added a comment last week in the vcs issue linked, but I am guessing this is something only @NathanReb is notified about.

I have simplified my use case in some projects where I am really simply trying to use deriving_inline in the lint phase, with no preprocessing otherwise (so, this is a simpler case that that of this issue, which was originally trying to have ppx in both modes along side each other). The lint-only attempt only works for limited sub-cases ; as soon as you have more complex expressions, such as compare or equal, something in the generated code is such that the code is unstable through ocamlformat and thus there exists no stable state that satisfies both dune build \@lint and dune fmt.

CC @patricoferris (I am guessing August is probably a slow month with many folks out, please let me know when would be a good time to discuss. Thank you!). If this is unlikely to be worked on, I think I'll need to think about alternatives. Although, I think that abandoning this work would make me a little sad, because it seems we may be very close to having deriving_inline working as a handy tool to reduce build dependencies in some projects (for example, you can have sexp derivers with only a sexplib0 dependencies, without pulling ppx_sexp_conv and thus base, etc.). In my opinion that can have an impact to improve compatibility between different pockets of the Eco-system that are otherwise hard to re-conciliate (other motivational cases for me are about compare and equal, as mentioned). Thank you for your consideration.