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

ocamlc -i can generate a wrong signature #6323

Closed
vicuna opened this issue Feb 6, 2014 · 2 comments
Closed

ocamlc -i can generate a wrong signature #6323

vicuna opened this issue Feb 6, 2014 · 2 comments

Comments

@vicuna
Copy link

vicuna commented Feb 6, 2014

Original bug ID: 6323
Reporter: pw374
Assigned to: @garrigue
Status: closed (set by @garrigue on 2017-03-14T03:20:35Z)
Resolution: duplicate
Priority: normal
Severity: minor
Version: 4.01.0
Target version: later
Category: typing
Duplicate of: #4791
Has duplicate: #7402
Related to: #6324
Monitored by: @hcarty

Bug description

Sometimes ocamlc -i generates a wrong signature, and then, either the compiler will give a "helpful" error message by saying something like ... X.t ... is not the same as ... t ..., or it says something like "val x : t is not included in va x : t", which is not helpful at all.

Steps to reproduce

This generates a rather understandable error:
cat > a.ml <<EOF
type t = A

module X =
struct
type t = B
let x = A
end
EOF
ocamlc -i a.ml > a.mli
ocamlc -c a.mli
ocamlc -c a.ml # this one fails but I'm nearly okay with it because it's possible to guess what's wrong from the error message and fix it.

But this gives an error that's very hard to understand, especially when the program is not that small:

cat > b.ml <<EOF
type 'a t = B of 'a t list

let rec foo f = function
| B(v)::tl -> B(foo f v)::foo f tl
| [] -> []

module DT = struct
type 'a t = {bar : 'a}
let p t = foo (fun x -> x) t
end
EOF
ocamlc -i b.ml > b.mli
ocamlc -c b.mli
ocamlc -c b.ml # this one fails and the error message bothers me a lot because the error message is virtually impossible to understand when the program is fairly larger than this toy example.

Additional information

I guess that either ocamlc -i should never generate an interface that won't compile, or the error message for the second example (i.e., b.ml) should be improved.

In the case where it's chosen that it's acceptable for ocamlc -i to generate interfaces that won't compile, I believe it should at least give warnings or provide ways to track down the "generated errors".

@vicuna
Copy link
Author

vicuna commented Feb 6, 2014

Comment author: kaustuv

I've run into this issue numerous times as well. I've stopped naming my types "t" as a result of this and a related issue [1].

I think the compiler should reject a module whose visible values have un-namable types. This augments the current heuristic that the same type name cannot be introduced in the same scope more than once.

[1] functors like Set.Make cannot be instantiated with a module with a carrier type of "t" if "t" is already visible. For some reason, type t = t is taken as a recursive type abbreviation, which breaks a common use case to support a baroque corner case (-rectypes)!

@vicuna
Copy link
Author

vicuna commented Jul 16, 2014

Comment author: @damiendoligez

ocamlc -i originates as a kind of "verbose" option and was not implemented as a well-thought-out must-work-in-all-cases interface-generation tool.
We might want to turn it into one, but that will probably involve a large amount of work.

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

2 participants