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
Type errors at the module level are puzzling #7336
Comments
Comment author: @sliquister I think the problem is Includemod calls Includecore.value_descriptions, which calls Ctype.more_general, which drops the Unify exception and returns a boolean instead. |
Comment author: @trefis Follow-up: since #792 was merged (in 4.06) I believe the example can be reduced to: module type S = sig
type ('a, 'b) t
type 'a key
val fold :
('a, 'b) t -> init:'c -> f:(key:'a key -> data:'b -> 'c -> 'c) -> 'c
end
module M : S with type 'a key = 'a = struct
type ('a, 'b) t
type 'a key = 'a
let fold = assert false
end
type ('a, 'b) t = ('a, 'b) M.t
module Make(Key : sig type t end) = struct
type nonrec 'a t = (Key.t, 'a) t
(* roughly equivalent type error at the value level:
type a type b type c
let x : (a, b) hashtbl -> init:c -> f:(key:a M.key -> data:b -> c -> c) -> c = assert false
let y : (a, b) t1 -> init:c -> f:(key:Key.t -> data:b -> c -> c) -> c = assert false
let _ = if true then x else y
*)
include (M : S
with type ('a, 'b) t := 'a t
with type 'a key := Key.t)
end Which gives the following error messages (when running without -short-paths):
When trying it with #1737 the last two lines become:
While this is very slightly better, it's indeed still fairly confusing. |
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 think the bug is still valid: we should expose the unification trace in case of signature item mismatch. IIRC, the additional information exposed by #9331 should make that easier to achieve. |
@Drup could you submit a testsuite PR that contains the current behavior, in a |
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. |
See #10407 for a possible solution to this issue. |
There is a label "error-messages", I suggest to assign it to this issue, it will finding all these error message improvements easier: |
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 current error message has been extended to include the error trace:
which does point to incompatibility for the type of data. Let's thus close this issue. |
Original bug ID: 7336
Reporter: @sliquister
Status: acknowledged (set by @xavierleroy on 2017-02-18T17:24:17Z)
Resolution: open
Priority: normal
Severity: feature
Version: 4.03.0
Target version: 4.07.0+dev/beta2/rc1/rc2
Category: typing
Child of: #7338
Monitored by: @gasche
Bug description
I got the following (legitimate) type error today:
while building something I reduced to [1]. The details of the code or the error are not very important, the point is I was not able to figure out what the problem is until someone helped me, because the types printed are what I expect. It turns out the bug was in the definition of t1.
I think the type error reporting is not as good at the module level. I don't think I'm ever confused like that by errors that don't involve modules. Contrast with an error involving the same types, but when there is no module in sight:
I'd like the typer to give this kind of error at the module level too. If this error had been given, I would have probably found the problem right away.
(Here, it probably didn't help that we are forced to create useless types, t1 and key1, to use destructive substitutions, because now they show up in type errors. I'm trying to lift that restriction.)
[1]
The text was updated successfully, but these errors were encountered: