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
Assertion failure in typing/printtyp.ml line 583-ish #6836
Comments
Comment author: dsheets Ugh. Those links should be mirage/ocaml-cohttp@c429f5e#diff-19a3a7db54ab863fd07186df30450b0eR37 and https://travis-ci.org/mirage/ocaml-cohttp/jobs/57781176#L3082 because '>' is not a valid URI character and is traditionally used to indicate the end of a URI. |
Comment author: dsheets The following crashes utop (but not the toplevel) with the same exception: module M = struct type 'a t = 'a let return a = a end module F(M : sig module A = F(M) A.q ();; |
Comment author: dsheets This issue was reported as a utop issue about 1 year ago by nojb: ocaml-community/utop#60 |
Comment author: @yallop You can crash the toplevel or ocamlc if you pass -short-paths: $ cat bug.ml module F(M : sig type 'a t end) : sig module A = F(M) let f () = A.q () |
Comment author: dsheets In my initial case, removing -short-paths avoids the assertion error and there is no masked type error. In this case, using -short-paths prevents an otherwise correct ml file from being built into a cmo. |
Comment author: @damiendoligez For future reference, I needed the following commands to trigger the repro case: git clone https://github.com/dsheets/ocaml-cohttp.git |
Comment author: @yallop
I'm not sure I understand the distinction (if there is a distinction). It appears that in both cases using -short-paths triggers an assertion error, aborting the compilation of a correct program. |
Comment author: dsheets There is no grand distinction. In your example bug.ml, without -i, the cmo builds fine. I was just wanting to make clear that the assertion error can occur even when type printing is not obviously involved. In that case (the original), an otherwise correct program is not built. |
Comment author: @yallop Ah, I see. Either -i or -annot will trigger the problem, I think. |
Comment author: @garrigue Wrong assumption... Fixed in trunk and 4.02 at revisions 16013 and 16014. Note that outcometree is actually incorrect: it requires the row name to be a constructor, but the parser allows any type expression. Fixing this would simplify the code. |
Original bug ID: 6836
Reporter: dsheets
Assigned to: @garrigue
Status: closed (set by @xavierleroy on 2016-12-07T10:47:33Z)
Resolution: fixed
Priority: normal
Severity: minor
Version: 4.02.1
Target version: 4.02.2+dev / +rc1
Fixed in version: 4.02.2+dev / +rc1
Category: typing
Monitored by: @diml
Bug description
When typing the function at < mirage/ocaml-cohttp@c429f5e#diff-19a3a7db54ab863fd07186df30450b0eR37 >, instead of a type error, an assertion failure occurs < https://travis-ci.org/mirage/ocaml-cohttp/jobs/57781176#L3082 >:
Fatal error: exception File "typing/printtyp.ml", line 583, characters 12-18: Assertion failed
Steps to reproduce
Additional information
The same assertion (on slightly different lines) is triggered by this same code in 4.01.0, 4.02.1, and 4.03.0+trunk.
I'm sorry I don't have a more reduced test case available. Reduction would be easiest with an instrumented compiler.
The text was updated successfully, but these errors were encountered: