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: 6880 Reporter: @sliquister Assigned to:@garrigue Status: closed (set by @xavierleroy on 2017-02-16T14:16:29Z) Resolution: fixed Priority: normal Severity: minor Version: 4.02.1 Target version: 4.03.0+dev / +beta1 Fixed in version: 4.03.0+dev / +beta1 Category: typing Monitored by:@gasche
Bug description
Trying to access components from dangling module aliases makes the typer simpler complain about not finding these specific components, instead of complaining about not finding the cmi for the module.
Assuming warning 49 is enabled, the output does contain enough information to figure out what went wrong, but if someone reads the resulting type error before the warning, it could lead to confusion. Given that some error messages are good, I think the bad error are not intended, but just the result of missing exception handling in some code paths.
Steps to reproduce
$ cat a.ml
module B = B
let () = B.x
$ ocamlopt -w @A -no-alias-deps -c a.ml
File "none", line 1:
Warning 49: no cmi file was found in path for module B
File "a.ml", line 2, characters 9-12:
Error: Unbound value B.x
The same thing happens with 'type t = B.t'.
Contrast with passing the alias to a functor (or including it, or packing it):
$ cat a.ml
module B = B
module C = Map.Make(B)
$ ocamlopt -w @A -no-alias-deps -c a.ml
File "none", line 1:
Warning 49: no cmi file was found in path for module B
File "a.ml", line 3, characters 20-21:
Error: Internal path B is dangling.
The compiled interface for module B was not found.
More weirdness with open:
$ cat a.ml
module B = B
open B
$ ocamlopt -w @A -no-alias-deps -c a.ml
File "none", line 1:
Warning 49: no cmi file was found in path for module B
File "a.ml", line 2, characters 5-6:
Error: This module is not a structure; it has type (module B)
And we have yet another confusing error with applicative functor application in types:
$ cat a.ml
module B = B
type t = Map.Make(B).t
$ ocamlopt -w @A -no-alias-deps -c a.ml
File "none", line 1:
Warning 49: no cmi file was found in path for module B
File "a.ml", line 2, characters 9-22:
Error: Ill-typed functor application Map.Make(B)
An other error message that I am not sure is intended:
$ cat a.ml
module B = B
module type S = module type of B
module M : S = struct end
$ ocamlopt -w @A -no-alias-deps -c a.ml
File "none", line 1:
Warning 49: no cmi file was found in path for module B
File "a.ml", line 3, characters 15-25:
Error: Signature mismatch:
Modules do not match: sig end is not included in S
The text was updated successfully, but these errors were encountered:
I will try to look into this, but originally 49 was made a warning rather than a hard error because it was not completely clear whether these access attempts were really wrong (in some cases, undefined types are allowed, and we don't want to break working programs).
Also, the cause being very deep, it may hard to find a meaningful location for the error.
File "none", line 1:
Warning 49: no cmi file was found in path for module B
File "a.ml", line 2, characters 9-12:
Error: The module B is an alias for module B, which is missing
module B = B
open B
gives
File "none", line 1:
Warning 49: no cmi file was found in path for module B
File "a.ml", line 2, characters 5-6:
Error: This is an alias for module B, which is missing
I'll see if I can extend it to cover the other two as well.
Original bug ID: 6880
Reporter: @sliquister
Assigned to: @garrigue
Status: closed (set by @xavierleroy on 2017-02-16T14:16:29Z)
Resolution: fixed
Priority: normal
Severity: minor
Version: 4.02.1
Target version: 4.03.0+dev / +beta1
Fixed in version: 4.03.0+dev / +beta1
Category: typing
Monitored by: @gasche
Bug description
Trying to access components from dangling module aliases makes the typer simpler complain about not finding these specific components, instead of complaining about not finding the cmi for the module.
Assuming warning 49 is enabled, the output does contain enough information to figure out what went wrong, but if someone reads the resulting type error before the warning, it could lead to confusion. Given that some error messages are good, I think the bad error are not intended, but just the result of missing exception handling in some code paths.
Steps to reproduce
$ cat a.ml
module B = B
let () = B.x
$ ocamlopt -w @A -no-alias-deps -c a.ml
File "none", line 1:
Warning 49: no cmi file was found in path for module B
File "a.ml", line 2, characters 9-12:
Error: Unbound value B.x
The same thing happens with 'type t = B.t'.
Contrast with passing the alias to a functor (or including it, or packing it):
$ cat a.ml
module B = B
module C = Map.Make(B)
$ ocamlopt -w @A -no-alias-deps -c a.ml
File "none", line 1:
Warning 49: no cmi file was found in path for module B
File "a.ml", line 3, characters 20-21:
Error: Internal path B is dangling.
The compiled interface for module B was not found.
More weirdness with open:
$ cat a.ml
module B = B
open B
$ ocamlopt -w @A -no-alias-deps -c a.ml
File "none", line 1:
Warning 49: no cmi file was found in path for module B
File "a.ml", line 2, characters 5-6:
Error: This module is not a structure; it has type (module B)
And we have yet another confusing error with applicative functor application in types:
$ cat a.ml
module B = B
type t = Map.Make(B).t
$ ocamlopt -w @A -no-alias-deps -c a.ml
File "none", line 1:
Warning 49: no cmi file was found in path for module B
File "a.ml", line 2, characters 9-22:
Error: Ill-typed functor application Map.Make(B)
An other error message that I am not sure is intended:
$ cat a.ml
module B = B
module type S = module type of B
module M : S = struct end
$ ocamlopt -w @A -no-alias-deps -c a.ml
File "none", line 1:
Warning 49: no cmi file was found in path for module B
File "a.ml", line 3, characters 15-25:
Error: Signature mismatch:
Modules do not match: sig end is not included in S
The text was updated successfully, but these errors were encountered: