Skip to content

Fix module+GADT typechecking regression#11339

Closed
mrmr1993 wants to merge 2 commits intoocaml:trunkfrom
mrmr1993:fix/gadt-module-regression-4.13
Closed

Fix module+GADT typechecking regression#11339
mrmr1993 wants to merge 2 commits intoocaml:trunkfrom
mrmr1993:fix/gadt-module-regression-4.13

Conversation

@mrmr1993
Copy link
Copy Markdown
Contributor

This PR fixes the regression described in #10768. This regression was introduced between 4.12 and 4.13 in eed1110, as part of PR #10277.


This PR introduces Ctype.wrap_no_update_gadt_scopes, which can be used to disable scope checks in Ctype.expand_abbrev_gen. By calling this in Includemod.signatures, modules inside expressions can still be constrained by signatures or packed/unpacked while they contain types with GADT equalities.

The scope checks are only skipped when a module is constrained to a signature, which happens when we are either packing a module, annotating a module with a signature, or applying a functor. All of these thus require an explicit signature at some point in the affected program. As far as I can tell, none of these provide a vector for re-introducing the 'ambiguous results of applications' problem that #10277 was intended to solve.

The attached testsuite builds on the example cases in #10768, and introduces some extra failure cases related to the tests from #10277 as an extra sanity check.

cc @garrigue

mrmr1993 added 2 commits June 21, 2022 02:01
This regression was introduced in
eed1110, as part of PR ocaml#10277.

This change introduces `Ctype.wrap_no_update_gadt_scopes`, used to
disable scope checks in `Ctype.expand_abbrev_gen`. By using this wrapper
in `Includemod.signatures`, modules inside expressions can still be
constrained by signatures and packed/unpacked while containing types
with GADT equalities.

The only way that these checks can be run is by providing an explicit
module signature, either by packing a module, annotating a module with a
signature, or applying a functor. This avoids re-introducing the
'ambiguous results of applications' problem that ocaml#10277 was intended to
solve.
@garrigue
Copy link
Copy Markdown
Contributor

For the record, #10348 does not help here, as it fixes unification, but the problem here comes from the use of expansion in moregeneral or eqtype.

Whether the fix preserves ambivalence is not completely clear to me.
Another approach would be to take fresh copies of the signatures involved (using `Subst.modtype Subst.identity). This is a bit more expensive, but you do not run the risk of modifying some type under the hood.

@garrigue
Copy link
Copy Markdown
Contributor

FWIW, here is the diff for the substitution approach. It appears to work with the example in #10768.
I didn't check with your extra examples.

--- a/typing/typemod.ml
+++ b/typing/typemod.ml
@@ -2062,9 +2062,11 @@ let () = Ctype.package_subtype := package_subtype
 
 let wrap_constraint env mark arg mty explicit =
   let mark = if mark then Includemod.Mark_both else Includemod.Mark_neither in
+  let mty1 = Subst.modtype Keep Subst.identity arg.mod_type in
+  let mty2 = Subst.modtype Keep Subst.identity mty in
   let coercion =
     try
-      Includemod.modtypes ~loc:arg.mod_loc env ~mark arg.mod_type mty
+      Includemod.modtypes ~loc:arg.mod_loc env ~mark mty1 mty2
     with Includemod.Error msg ->
       raise(Error(arg.mod_loc, env, Not_included msg)) in
   { mod_desc = Tmod_constraint(arg, mty, explicit, coercion);

@garrigue garrigue mentioned this pull request Jun 21, 2022
@garrigue
Copy link
Copy Markdown
Contributor

For safety reasons, I would rather go with the fix in #11340: copying cannot break anything, while disabling checks on shared types seems potentially dangerous.
Thank you very much for your analysis and examples, that made finding the fix extremely easy.

@mrmr1993
Copy link
Copy Markdown
Contributor Author

For safety reasons, I would rather go with the fix in #11340: copying cannot break anything, while disabling checks on shared types seems potentially dangerous.

That makes sense, and your changes LGTM. Closing this in favour of your PR, thanks for the quick turn-around!

@mrmr1993 mrmr1993 closed this Jun 21, 2022
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