-
Notifications
You must be signed in to change notification settings - Fork 99
Dev Meeting 2024 07 23
- Plan to drop warning silencing
- 0.33.0 release
- 5.2 AST Bump
- In general what is the medium term goals for ppxlib? Mostly maintenance and bumping the AST/keeping up with compiler releases?
- This agenda item was postponed to the next ppxlib dev meeting.
- Nathan
- Patrick
- Sonja
A new PR adds a feature that would allow users to lookup a deriver via ppxlib's API. This makes it easier to, for example, combine multiple ppx derivers under one alias (e.g. [@@deriving std] could enable yojson, show etc.)
The design is perhaps not ideal. If the original derivers aren't installed, the errors will be very misleading. The only advantage of that approach over ppx_jane-style approach would be that the wrapped derivers don't need to retain their original name.
Instead of looking up derivers then, it was decided that we should update documentation and examples to include exposing the deriving t so people can alias it themselves by including the library of the ppx in their project.
The problem we are trying to overcome is how to deal with features in deriving that disable unused value declarations, unused modules and unused types. These were all generated by any ppxlib deriving plugin. This was for convenience. It was fairly common for a deriving ppx to generate two functions foo and bar unconditionally that do not depend on each other but with no means to disable either foo or bar from being generated.
It was noticed when using bisect_ppx -- deriving ended up making bisect_ppx say 99% coverage! It might be better to go case by case and/or tweak derivers to be used in a way that doesn't generate the warnings.
We now have some flags to enable or disable this behaviour but also depends on if the plugin allows it.
Flags have true, false and force with force ignoring the plugin's desire for how warning are silenced.
Ppxlib can try to move the community to disabling the silencing.
This was a somewhat painful process and for a release that does not bump the AST or making too many breaking changes. The major issue is that opam-repo-ci is was struggling to provide good information about reverse dependencies and timeout failures. False positives on reverse dependency builds (and also from packages that have simply never built). Mostly the error messages are good but not always. We are getting more and more errors. This is not manageable in the long run.
A good first fix for this is that opam-repo-ci adds better timeout handling support and mention if something didn't build before this current testing.
There is now a draft PR bumping the AST to OCaml 5.2.0! Included in this work was the development of a prototype reverse dependency CI which showed just how much this change might break (in particular with the new handling of function arities that has landed in OCaml)[https://github.com/ocaml/ocaml/pull/12236].