Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Typecore.force_delayed_checks does not run with -i option. #7620

Closed
vicuna opened this issue Sep 5, 2017 · 6 comments
Closed

Typecore.force_delayed_checks does not run with -i option. #7620

vicuna opened this issue Sep 5, 2017 · 6 comments

Comments

@vicuna
Copy link

vicuna commented Sep 5, 2017

Original bug ID: 7620
Reporter: furuse
Assigned to: @garrigue
Status: resolved (set by @garrigue on 2017-09-12T23:38:15Z)
Resolution: fixed
Priority: normal
Severity: minor
Version: 4.05.0
Fixed in version: 4.06.0 +dev/beta1/beta2/rc1
Category: compiler driver

Bug description

The following program passes ocamlc -i, but not ocamlc:


let t =
(function A | B -> () : 'a) (A : [A]);
(failwith "dummy" : 'a) (* to know how 'a is unified *)

With ocamlc -i,


val t : [ `A ] -> unit

but with ocamlc


File "x.ml", line 2, characters 17-19:
Error: This pattern matches values of type [? B ] but a pattern was expected which matches values of type [ A ]
The second variant type does not allow tag(s) `B

This is because Typecore.force_delayed_checks never runs when -i option is given.

There is another issue of Typecore.force_delayed_checks: it runs only after printing the module signature in Compile.interface and Optcompile.interface.

I think they are bugs, but are they done intentionally? Even if they are intentional, Typecore.force_delayed_checks must run after printing the signatures for ocamlc -i.

@vicuna
Copy link
Author

vicuna commented Sep 5, 2017

Comment author: @garrigue

This is clearly a bug. Going to fix it.

@vicuna
Copy link
Author

vicuna commented Sep 5, 2017

Comment author: @garrigue

Actually, this is more complicated than I thought:
force_delayed_checks is also used for unused definition warning, which is dependent on the presence of an mli.
This is why it was moved outside of the -i path.
The answer is probably that we should disable unused definition warnings when -i is used...
Alain, any comment?

@vicuna
Copy link
Author

vicuna commented Sep 5, 2017

Comment author: @garrigue

Tentative fix: #1317

@vicuna
Copy link
Author

vicuna commented Sep 6, 2017

Comment author: furuse

BTW, why is it handled as a type error? Is there an example to break the type safety by changing it to a warning?

FYI, the example was found in a use of ppx_implicits, where, roughly speaking, pre-process a typed code, for example, from

(function A | B -> ()) (assert false)

to

(function A | B -> ()) (A : [A])

It relies heavily on the principal type property, but it is broken here...

@vicuna
Copy link
Author

vicuna commented Sep 12, 2017

Comment author: @garrigue

Fixed in trunk by commit e286dbd.
Call Typecore.force_delayed_checks before printing the signature for ocamlc -i.

@vicuna vicuna closed this as completed Sep 12, 2017
@vicuna
Copy link
Author

vicuna commented Sep 12, 2017

Comment author: @garrigue

@furuse, is your question about the fix, or about the original behavior?

Note that the value restriction breaks the principal type property from the beginning (non-generalizable type variables are not allowed to remain in compilation units).

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

No branches or pull requests

2 participants