ppx_deriving icon indicating copy to clipboard operation
ppx_deriving copied to clipboard

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

Open chetmurthy opened this issue 3 years ago • 6 comments

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.

chetmurthy avatar Nov 27 '20 03:11 chetmurthy

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?

gasche avatar Nov 27 '20 05:11 gasche

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 avatar Nov 27 '20 05:11 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.

chetmurthy avatar Nov 27 '20 05:11 chetmurthy

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 avatar Nov 27 '20 11:11 kit-ty-kate

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

kit-ty-kate avatar Nov 27 '20 11:11 kit-ty-kate

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

sim642 avatar Jul 26 '22 07:07 sim642