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

-short-paths sometimes does not shorten paths #6380

Closed
vicuna opened this issue Apr 25, 2014 · 7 comments
Closed

-short-paths sometimes does not shorten paths #6380

vicuna opened this issue Apr 25, 2014 · 7 comments

Comments

@vicuna
Copy link

vicuna commented Apr 25, 2014

Original bug ID: 6380
Reporter: @sliquister
Assigned to: @lpw25
Status: assigned (set by @garrigue on 2017-03-14T08:08:21Z)
Resolution: open
Priority: normal
Severity: feature
Version: 4.01.0
Target version: undecided
Category: typing
Monitored by: @hcarty

Bug description

When type errors happen while matching a .ml against with its interface, -short-paths seems to have no effect.
In the type error below, I'd expect to see "val a : unit -> t" instead of "val a : unit -> A.Std.t".

Steps to reproduce

$ cat a.ml
module Std = struct
type t
end
$ ocamlopt -c -short-paths a.ml
$ cat b2.mli
open A.Std
val a : unit -> t
$ ocamlopt -c -short-paths b2.mli
$ cat b2.ml
open A.Std
let a = ()
$ ocamlopt -c -short-paths b2.ml
File "b2.ml", line 1:
Error: The implementation b2.ml does not match the interface b2.cmi:
Values do not match:
val a : unit
is not included in
val a : unit -> A.Std.t
File "b2.ml", line 2, characters 4-5: Actual declaration

@vicuna
Copy link
Author

vicuna commented Jun 4, 2014

Comment author: @damiendoligez

reproduced on 4.02.0+dev

@vicuna
Copy link
Author

vicuna commented Mar 14, 2017

Comment author: @lpw25

I've marked this as a feature because it is not actually a bug. The issue is that those open statements are inside the module. So they are not in the environment when we do the comparison and print the error.

If we want to make this work I think we need to have open statements be included in module types. They would only affect printing -- much like the names attached to type variables and similar. This would allow the module type to be printed as:

sig
open A.Std
val a : unit -> t
end

rather than:

sig
val a : unit -> A.Std.t
end

and similarly it would allow t to be used in the error message.

@github-actions
Copy link

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.

@github-actions github-actions bot added the Stale label May 13, 2020
@lpw25
Copy link
Contributor

lpw25 commented May 13, 2020

This probably still worth fixing. Maybe @Octachron would be interested in it since he's done a lot to improve the error printing.

@Octachron
Copy link
Member

It sounds potentially interesting. Similarly, I remember that @Drup was working on enriching module types with at least include statement at some point. @Drup, did you add open too or only include?

@Drup
Copy link
Contributor

Drup commented May 21, 2020

I didn't but it could be considered, yes.

@github-actions github-actions bot removed the Stale label Jun 17, 2020
@github-actions
Copy link

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.

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

4 participants