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
False typing error when using pre-compiled .cmi through -intf-suffix option #7629
Comments
Comment author: @lpw25 I had a brief look at this and it seemed like it was another failure of reflexivity for type equality with polymorphic variant conjunctions. It seems to rely on both a module alias and a recursive type, so I suspect something around the type expansion code. |
Comment author: @Octachron I found another example of this issue (or something quite similar) using polymorphic variant but neither module aliases nor recursive type: type 'a one = [`one of 'a]
type 'a two = [`two of 'a]
type 'a three = [`three of 'a]
type ( 'dim, 'res, 'p1 ) cross =
[< `two of 'res & 'p1 one | `three of 'res & 'p1 three ] as 'dim
type 'dim t
let cross:('dim, 'dim2, _ ) cross t ->
'dim t -> 'dim2 t = fun _ _ -> assert false
let fn v w = cross v w |
This issue has been open one year with no activity. Consequently, it is being marked with the "stale" label. What this means is that the issue will be automatically closed in 30 days unless more comments are added or the "stale" label is removed. Comments that provide new information on the issue are especially welcome: is it still reproducible? did it appear in other contexts? how critical is it? etc. |
The issue still exists, and is exotic enough to warrant being recorded. |
This issue has been open one year with no activity. Consequently, it is being marked with the "stale" label. What this means is that the issue will be automatically closed in 30 days unless more comments are added or the "stale" label is removed. Comments that provide new information on the issue are especially welcome: is it still reproducible? did it appear in other contexts? how critical is it? etc. |
I reproduced @Octachron's example in the current trunk, now with a much longer error message.
|
This issue has been open one year with no activity. Consequently, it is being marked with the "stale" label. What this means is that the issue will be automatically closed in 30 days unless more comments are added or the "stale" label is removed. Comments that provide new information on the issue are especially welcome: is it still reproducible? did it appear in other contexts? how critical is it? etc. |
The bug still exists and is still a witness of an exotic type system corner case. |
Original bug ID: 7629
Reporter: jacquev6
Status: acknowledged (set by @xavierleroy on 2017-09-30T08:40:50Z)
Resolution: open
Priority: normal
Severity: minor
Version: 4.02.3
Category: typing
Monitored by: jacquev6 @yakobowski
Bug description
Compiling the attached code in two steps, using -intf-suffix .ml to re-use the .cmi produced in the first step, leads to a false typing error:
Note that the expected and the actual type for g are exactly the same. And that there is only a .ml file, so there can't be any inconsistency between .ml and .mli file.
The code to exhibit this issue is rather complex: it contains a module alias, a recursive function, and uses a dynamic variant to make a recursive type from a parametric type. I think all are needed to exhibit the issue.
Context:
I was porting some code to jbuilder. After reducing my code to a minimal example, I reported the issue to jbuilder in ocaml/dune#254 and after investigation, Xavier Clerc says it's a compiler issue.
Jbuilder uses -intf-suffix to compile a .ml-only module to native after compiling it byte, in order to to re-use the .cmi file, as explained in this comment: ocaml/dune#254 (comment)
Steps to reproduce
Download test.ml (attached to this Mantis issue)
Create test.cmi:
ocamlc -c test.ml
Compile:
ocamlc -intf-suffix .ml test.ml -o test
Observe:
Additional information
Possible workaround:
(suggested by Leo White in this comment: ocaml/dune#254 (comment))
Add a polymorphic type annotation to g:
Versions tested:
Same behavior in 4.02.3 and 4.05.0+flambda, both on Linux and macOS.
File attachments
The text was updated successfully, but these errors were encountered: