new bug in ppx_deriving ("optional" no longer works)

[chetmurthy]

Versions:
bash --login -c "RUN -s Opam-2.1.0 opam show ppx_deriving "

<><> ppx_deriving: information on all versions ><><><><><><><><><><><><><><><><>
name ppx_deriving
all-installed-versions 5.2 [4.11.1]

test file foo.ml:

type a1 = int        [@@deriving show, arglebargle { optional = true }]

failing run:

bash --login -c "RUN -s Opam-2.1.0 ocamlfind ocamlc -package ppx_deriving.show -c foo.ml  "
File "foo.ml", line 1, characters 39-70:
1 | type a1 = int        [@@deriving show, arglebargle { optional = true }]
                                           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Error: Ppxlib.Deriving: 'arglebargle' is not a supported type deriving
       generator

I guess this is a bug? I don't use ppx_deriving, except in unit-tests to verify that I'm adhering to the same semantics in my camlp5-based pa_ppx type-derivers, but figured I should report it anyway.

[gasche]

What the error message suggests, from a distance, is not a difference of support of optional, but that deriver names that are not registered are turned into errors. I must say that I did not check the behavior in the past, but you seem to suggest that they were silently ignored?

[chetmurthy]

Yes, that is the behaviour that worked in the past. Also, documented:

It's possible to make deriving ignore a missing plugin rather than raising an error by passing an optional = true option, for example, to enable conditional compilation:

type addr = string * int
[@@deriving yojson { optional = true }]

And finally, there's a test test_ppx_derivint.ml in the source code:

type optional_deriver = string
[@@deriving missing { optional = true }]

[chetmurthy]

BTW, obviously I don't -depend- on this behaviour. I just need to ensure that my unit-tests work with ppx_deriving as identically as possible, as with my own PPX type-deriving infrastructure.

[kit-ty-kate]

I believe this is an inherent part of ppxlib's design and it's something that we want as it helps users in case they forgot to pass the correct ppx. I'll update the documentation accordingly.

[kit-ty-kate]

oh sorry nevermind I didn't read the message entirely (sorry I'm tired). Mh, I'll have a look.

[sim642]

This issue is due to mixed use of ppx_deriving and ppxlib derivers. The error really comes from ppxlib, where the corresponding issue is ocaml-ppx/ppxlib#125, just to connect the dots. Apparently there is an actual user of the feature.