-
Notifications
You must be signed in to change notification settings - Fork 1.1k
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
Internal error inocamlc
on extreme code: Ctype.Nondep_cannot_erase
#12014
Comments
This is the high-level error message that is producing the internal error. I expect that this happens when the diffing algorithm is exploring the possibility that there is a missing argument with the correct type. This is worth some investigation to see if that can be easily corrected. |
This is probably the expected behavior. It is presumably looping when evaluating the definition of |
Although this issue is open, this bug appears to be fixed in 5.1.0 and trunk. I came here to report a simpler program that was triggering the same error (provided by @ceastlund, and copied below). But I was using 4.14, and testing quickly on 5.1.0 and trunk shows that both the smaller program and the above example now give nice type errors rather than crashing the compiler. Here's the smaller program that was triggering the same issue on 4.14: module type A = sig
type t
end
module type B = sig
type t
module type A = A with type t := t
val a : (module A)
end
module F (B : B) : B.A = (val assert false : B.A)
module G (B : B with type t := int) = struct
let a : (module B.A) = (module F ((val B.a)))
end |
Should we consider closing this issue, then, if it was resolved in 5.1.0? (cc @Octachron) |
Just as future reference, a smaller example is given by : module type Type = sig module type T end
module F(A:Type)(X:A.T) = X
module Crash = F(struct module T = struct end end) (* should be module type T, not module T*) Note that the name clash can also happen with type constructor, i.e. this also crashes: module Crash' = F(struct type t = T end) |
For the record, I've checked that @Octachron's 670aeb8 fixes @clementblaudeau's example (#12014 (comment)), @ccasin's example (#12014 (comment)) and @joelatschool's example (#12821). |
Thanks @yallop! @Octachron, do we want to backport this to the 4.14 branch? |
Backporting #12063 to 4.14 sounds like a sensible option to me, I will open a PR to do so. |
Steps to Reproduce
See "UPDATE" below for a smaller repro
using ocaml 5.0.0, tested on Mac 13.1 (22C65) with M1
ocamlc girard.ml
source: https://github.com/mheiber/girards-paradox/blob/2bbcb77/girard.ml
girard.ml
is the same as https://github.com/lpw25/girards-paradox/blob/17ccd5d/girard.ml, with the following line appended:module M = Paradox(struct let one = 1 end)
Here are some relevant definitions in girard.ml:
Actual Behavior
Fatal error
Expected Behavior
No internal compiler error.
The ideal would be an error like this:
An error message like this makes sense to me, since the argument to
Paradox
is wrong.Paradox
is a functor expecting aType
, which has a membermodule type T
.Related behaviors
ocamlopt girard.ml
shows a similar internal compiler error to the one forocamlc
aboveocaml girard.ml
hangs on this code. The code isn't expected to diverge, if I understand @lpw25's comment here correctly: Are you able to extend this to make the type checker diverge? lpw25/girards-paradox#1.Related issues
Nondep_cannot_erase
appeared in fatals previously due to a since-fixed issue: Compiler fails with Ctype.Nondep_cannot_erase exception. #9858Update
This is a smaller repro:
ocamlc girard.ml
orocamlopt girard.ml
with this file https://github.com/mheiber/girards-paradox/blob/1052486/girard.ml produces the same errr stack.ocaml girard.ml
with this file does not hang, unlike with the original repro.The text was updated successfully, but these errors were encountered: