Skip to content

Support 5.5 Compiler#622

Open
patricoferris wants to merge 2 commits intoocaml-ppx:mainfrom
patricoferris:5.5-migrations
Open

Support 5.5 Compiler#622
patricoferris wants to merge 2 commits intoocaml-ppx:mainfrom
patricoferris:5.5-migrations

Conversation

@patricoferris
Copy link
Collaborator

This adds further support for the 5.5 compiler (#620). In particular it adds full migrations for modular explicits and external type declarations. This PR will require ocaml/ocaml#14518 to fix the tests for external types.

Our migrations can now support modular explicits. This also required a
fix to how we were migrating Ppat_unpack too.

Signed-off-by: Patrick Ferris <patrick@sirref.org>
Signed-off-by: Patrick Ferris <patrick@sirref.org>
Copy link
Collaborator

@NathanReb NathanReb left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'll sum up here some of the offline discussions we had:

  • Encode Ppat_unpack (_, Some _) as an extension point instead as it is semantically different from 5.4's Ppat_constraint (Ppat_unpack _, Ptyp_package _) and the attribute encoded version could too easily be tempered with in a breaking way.
  • external type declarations should be encoded in an extension point at the closest parent. We can keep the attribute based encoding inside the extension's payload but it has to be wrapped to avoid tempering or misinterpretation by existing ppx-es.
  • I think I like the encoding (as in a node gets encoded into an extension point) to be tested separately from regular migration.

Other than that it all looks good, I appreciate the detailed explanation in the test that really helped understanding the migrations. I wonder if we should add comments to non trivial migration code to provide context right next to it without having to jump elsewhere.

let mk_core_type ?(ptyp_attributes = []) ptyp_desc =
{
ptyp_desc;
ptyp_loc = Location.none;
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just to err on the safe side, I think we should use the node to encode's loc here!

> EOF

For now, we do not support these and raise an error. In the future we may wish
to encode this feature into attributes and this test, along with this comment,
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This comment should be removed!

@NathanReb
Copy link
Collaborator

We realized encoding Ppat_unpack (_, Some _) as an extension could cause preprocessing/compiling errors when building with 5.5 on source code that otherwise builds fine with older compilers, breaking backward compatibility and ruling out this solution.

See the discussions in ocaml/ocaml#14149 for Ppat_unpack for details but the prefered solution is:

  • migrate 5.4 Ppat_constraint (Ppat_unpack m, Ptyp_package s) to Ppat_unpack (m, Some s) by default or preserve the Ppat_constraint form if it is annotated with the right attribute
  • attach said attribute to Ppat_constraint (Ppat_unpack m, Ptyp_package s) when migrating form 5.5 to 5.4 so they round trip correctly

This preserves semantics and in the event that a ppx would temper with the attribute, the worst possible scenario doesn't lead to a compiler error anymore and instead turns an ill-typed program into a well typed one.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants