5.2.0~alpha1: Issues with (x : Subtype.t list :> Type.t list) in presence of multiple destructive substitutions

[kit-ty-kate]

5.2.0~alpha1: Issues with (x : Subtype.t list :> Type.t list) in presence of multiple destructive substitutions

[gasche]

I can't make a better guess than you did, so I would just try bisecting typing/ changes between 5.1 and 5.2.

[kit-ty-kate]

@Octachron made some progress debugging this in the meantime and it seems to be related to the preview of ppxlib we are using. Either one of us will close this if it's confirmed to be ppxlib-only issue

[Octachron]

This seems indeed increasingly likely to be a ppxlib issue. Typically, my reproduction case at https://github.com/Octachron/bug-reproduction-archives/tree/main/ppxlib_and_include fails with the reported error whenever a ppxlib-based ppx is used (even for an identity ppx).

[kit-ty-kate]

mmh, that's weird though, your example doesn't use any ppxlib feature other than the driver.
Ast_mapper.default_mapper is a function from compiler-libs. Maybe something is missing from there in 5.2

[kit-ty-kate]

oh nevermind i read the ppx / manual_ppx directories the wrong way, sorry for the noise

[gasche]

Random thought: could this be some fallout from however ppxlib adapted to the changes in #12119, #12191? This was done in 5.1, but it may be that ppxlib changed it after the 5.1 release and we are only testing the change opam-wide now.

[kit-ty-kate]

I've just tried the main branch of ppxlib and it works just fine there if that was what you were thinking.

However I also managed to reduce @Octachron's test case even more: Octachron/bug-reproduction-archives#1
and it turns out the issue is in the way private types are translated in ppxlib.

I'll close this issue to avoid further noise. The ppxlib maintainers have been notified.