Odd deriving error

Ecosystem
,
1

Here’s an odd bug I’m seeing which seems to have something to do with lens.ppx_deriving.

I have this code (somewhat simplified):

[%%transform
   module Foo = struct
      type t = int
    end]

where %%transform generates

   module Foo = struct
      type t = int [@@deriving bar]
    end

where bar is a deriver I’ve written. In most cases, that works fine. But if the dune preprocessing list includes lens.ppx_deriving, the deriver bar is not applied. Strangely, if I omit %%transform, and enter deriving bar manually, then bar is applied. Removing lens.ppx_deriving fixes the problem. Of course, I need that for some code.

What could cause the interaction between lens.ppx_deriving and my own deriver?

2

This looks like a driver issue. For recursive expansion to work (deriving attributes being expanded in a ppx output), the driver (thing that will apply the rewrites) has to explicitly support this use case. I believe that ppxlib supports this but OMP (ocaml migrate parsetree) does not. A possible cause for your problem is that ppx_deriving uses OMP which is not taken into account by ppxlib when doing the recursive expansion.