You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Original bug ID: 7402 Reporter: kosik Assigned to:@garrigue Status: closed (set by @garrigue on 2017-03-14T03:23:07Z) Resolution: duplicate Priority: normal Severity: minor Version: 4.02.3 Target version: later Category: typing Duplicate of:#4791#6323
Bug description
When I tried to use "ocamlc -i ..." command to generate "*.mli" files, I have noticed that the generated files are not always compilable (for various reasons).
I've attached the files that reproduce the problem in the simplest possible context.
but it generates "main.mli" which does not make sense:
module M : sig val v : M.t end
val v : M.t
Of course, an attempt to compile it fails:
ocamlc -c main.mli
File "main.mli", line 2, characters 8-11:
Error: Unbound type constructor M.t
I think this is a bug because if "ocamlc -i ..." generates a mli-file and exits with an exit-status 0, it is natural to assume that it is supposed to be compilable.
I am not sure what is the best way to fix this. There are at least two possibilities:
(1)
Considering the fact that this:
module M = struct end
module M = struct end
is already rejected by "ocamlc", it seems sensible to change the definition of the Ocaml language so that shadowing of global modules locally will not be allowed. Consequently, "ocamlc -i ..." can generate mli-file that makes sense.
(2)
Or we can keep the language definition as it is, (allowing shadowing of global modules locally, even though shadowing of local modules locally is already forbidden), and just make sure that if "ocamlc -i" cannot generate mli-file that is compilable, it will not generate anything, print a sensible error message (explaining to th user why that is not possible) and exit with an appropriate exit-code.
Original bug ID: 7402
Reporter: kosik
Assigned to: @garrigue
Status: closed (set by @garrigue on 2017-03-14T03:23:07Z)
Resolution: duplicate
Priority: normal
Severity: minor
Version: 4.02.3
Target version: later
Category: typing
Duplicate of: #4791 #6323
Bug description
When I tried to use "ocamlc -i ..." command to generate "*.mli" files, I have noticed that the generated files are not always compilable (for various reasons).
I've attached the files that reproduce the problem in the simplest possible context.
Individual files:
(* the contents of "m.mli" *)
type t
val v : t
???????????????????????????????????????????????????
(* the contents of "main.ml" *)
module M = struct
let v = M.v
end
let v = M.v
???????????????????????????????????????????????????
the contents of "Makefile"
main.cmi m.cmi : %.cmi : %.mli
ocamlc -c $<
main.mli : main.ml m.cmi$< > $ @
ocamlc -i
main.cmi : m.cmi
The following command (unsurprisingly) succeeds:
ocamlc -c m.mli
The following command "succeeds":
ocamlc -i main.ml > main.mli
but it generates "main.mli" which does not make sense:
module M : sig val v : M.t end
val v : M.t
Of course, an attempt to compile it fails:
ocamlc -c main.mli
I think this is a bug because if "ocamlc -i ..." generates a mli-file and exits with an exit-status 0, it is natural to assume that it is supposed to be compilable.
I am not sure what is the best way to fix this. There are at least two possibilities:
(1)
Considering the fact that this:
module M = struct end
module M = struct end
is already rejected by "ocamlc", it seems sensible to change the definition of the Ocaml language so that shadowing of global modules locally will not be allowed. Consequently, "ocamlc -i ..." can generate mli-file that makes sense.
(2)
Or we can keep the language definition as it is, (allowing shadowing of global modules locally, even though shadowing of local modules locally is already forbidden), and just make sure that if "ocamlc -i" cannot generate mli-file that is compilable, it will not generate anything, print a sensible error message (explaining to th user why that is not possible) and exit with an appropriate exit-code.
Steps to reproduce
tar xvzf files.tar.gz
make
File attachments
The text was updated successfully, but these errors were encountered: