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

Shadowing not handled correctly in .ml-generated .cmi #3545

Closed
vicuna opened this issue Mar 17, 2005 · 2 comments
Closed

Shadowing not handled correctly in .ml-generated .cmi #3545

vicuna opened this issue Mar 17, 2005 · 2 comments

Comments

@vicuna
Copy link

vicuna commented Mar 17, 2005

Original bug ID: 3545
Reporter: administrator
Status: closed (set by @xavierleroy on 2013-08-01T08:48:16Z)
Resolution: fixed
Priority: normal
Severity: feature
Category: ~DO NOT USE (was: OCaml general)
Monitored by: @gasche nogin

Bug description

Full_Name: Aleksey Nogin
Version: 3.08.2
OS: Mandrake Linux 10.0
Submission from: wasco.cs.caltech.edu (131.215.44.173)

If I have a .cmi that is generated by compiling a ".mli-free" .ml, and the .ml
has shadowing, then an attempt to re-compile .ml while type-checking against the
.cmi will fail with a type error!

% ocamlc -version
3.08.2

% ls x.*
x.ml

% cat x.ml
let x = 1

let x = "s"

% ocamlc -c x.ml

% ls x.*
x.cmi x.cmo x.ml

% ocamlopt -c -intf-suffix .cmi x.ml
The implementation x.ml does not match the interface x.cmi:
Values do not match: val x : string is not included in val x : int

P.S. You might wonder why one would want to do something like this in the first
place. Basically, I want to have build rules that would allow:
a) building both native and bytecode versions of an OCaml project
b) parallelized builds.

I want to be able to say that in the absence of .mli, the way to generate .cmi
file is to run ocamlc on .ml. The problem with is is that once the .cmi is
generated by the ocamlc, some "consumer" of that .cmi may end up running in
parallel with the ocamlopt for the .ml. Since ocamlopt would create the .cmi
again and will actually overwrite it in place, I am likely to get a "corrupted
.cmi" error message from the "consumer" process.

I was hoping to be able to solve this by using "ocamlopt -intf-suffix .cmi" for
compiling .ml files whenever building both native and bytecode versions. This
did not work because of this bug.

This "build rules" issue is discussed in slightly more detail in a bug report
for the OMake build system is http://bugzilla.metaprl.org/show_bug.cgi?id=421

@vicuna
Copy link
Author

vicuna commented Aug 8, 2005

Comment author: administrator

Obvious fix (attempted 2005-08-02 by XL) doesn't work. This bug is not
critical, so I'll leave it as feature wish.

@vicuna
Copy link
Author

vicuna commented Aug 1, 2013

Comment author: @xavierleroy

The issue appears fixed in 4.01. At some point in the past, inferred signatures were cleaned up w.r.t. multiple definitions. Closing this PR.

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

1 participant