0004816: module abbreviations remove 'private' type restrictions

(0004987)
garrigue (manager)
2009-06-08 04:37

Fixed in CVS for 3.11.1.
A previous fix for private abbreviations had broken the behaviour for private types...

(0004994)
jjb (reporter)
2009-06-13 00:04

I am still seeing different behavior with 3.11.1 regarding the typing of
private types. Consider the following code:

    module M : sig
      type t = private T of int
      val mk : int -> t
    end = struct
      type t = T of int
      let mk x = T(x)
    end

    module M1 : sig
      type t = M.t
      val mk : int -> t
    end = struct
      type t = M.t
      let mk = M.mk
    end

    module M2 : sig
      type t = M.t
      val mk : int -> t
    end = struct
      include M
    end

    module M3 : sig
      type t = M.t
      val mk : int -> t
    end = M

With 3.10.2 this type-checks, but with 3.11.1, M1 type-checks but M2 and M3
fail:

Error: Signature mismatch:
       Modules do not match:
         sig type t = M.t = private T of int val mk : int -> t end
       is not included in
         sig type t = M.t val mk : int -> t end
       Type declarations do not match:
         type t = M.t = private T of int
       is not included in
         type t = M.t

Note that M1, M2, and M3 have identical meanings.

(0004995)
garrigue (manager)
2009-06-13 12:31

Actually the second bug your report has a different cause.
Namely the case when the implementation type was a private concrete type,
and the interface type a public abbreviation referring to this type,
was incorrectly refused. The problem was in file includecore.ml.

This is fixed in CVS, branch 3.11, but too late for 3.11.1.

(0004996)
garrigue (manager)
2009-06-14 10:01

Question to the original reporter:

It seems that ocaml-3.11.1 shipped with a partial fix, sound (i.e. private types are really private), but not complete (some correct re-exportations are refused by the compiler). So some correct software that compiled with 3.11.0 will not compile with 3.11.1. How bad is it for you? Do you know of any published software where such a problem occurs?
Since 3.11.0 was no sound, there may be also programs that took advantage of the unsoundness, but then refusing them is certainly correct.

Issue History
Date Modified	Username	Field	Change
2009-06-07 18:37	jjb	New Issue
2009-06-08 04:37	garrigue	Note Added: 0004987
2009-06-08 04:37	garrigue	Status	new => closed
2009-06-08 04:37	garrigue	Resolution	open => fixed
2009-06-08 04:37	garrigue	Fixed in Version	=> 3.11.1+dev
2009-06-13 00:04	jjb	Note Added: 0004994
2009-06-13 00:04	jjb	Status	closed => feedback
2009-06-13 00:04	jjb	Resolution	fixed => reopened
2009-06-13 12:31	garrigue	Note Added: 0004995
2009-06-13 12:31	garrigue	Status	feedback => resolved
2009-06-13 12:31	garrigue	Resolution	reopened => fixed
2009-06-13 12:31	garrigue	Assigned To	=> garrigue
2009-06-14 10:01	garrigue	Note Added: 0004996
2009-12-04 19:14	xleroy	Relationship added	related to 0004933
2011-05-29 12:14	xleroy	Status	resolved => closed

Notes
(0004987) garrigue (manager) 2009-06-08 04:37	Fixed in CVS for 3.11.1. A previous fix for private abbreviations had broken the behaviour for private types...

(0004994) jjb (reporter) 2009-06-13 00:04	I am still seeing different behavior with 3.11.1 regarding the typing of private types. Consider the following code: module M : sig type t = private T of int val mk : int -> t end = struct type t = T of int let mk x = T(x) end module M1 : sig type t = M.t val mk : int -> t end = struct type t = M.t let mk = M.mk end module M2 : sig type t = M.t val mk : int -> t end = struct include M end module M3 : sig type t = M.t val mk : int -> t end = M With 3.10.2 this type-checks, but with 3.11.1, M1 type-checks but M2 and M3 fail: Error: Signature mismatch: Modules do not match: sig type t = M.t = private T of int val mk : int -> t end is not included in sig type t = M.t val mk : int -> t end Type declarations do not match: type t = M.t = private T of int is not included in type t = M.t Note that M1, M2, and M3 have identical meanings.

(0004995) garrigue (manager) 2009-06-13 12:31	Actually the second bug your report has a different cause. Namely the case when the implementation type was a private concrete type, and the interface type a public abbreviation referring to this type, was incorrectly refused. The problem was in file includecore.ml. This is fixed in CVS, branch 3.11, but too late for 3.11.1.

(0004996) garrigue (manager) 2009-06-14 10:01	Question to the original reporter: It seems that ocaml-3.11.1 shipped with a partial fix, sound (i.e. private types are really private), but not complete (some correct re-exportations are refused by the compiler). So some correct software that compiled with 3.11.0 will not compile with 3.11.1. How bad is it for you? Do you know of any published software where such a problem occurs? Since 3.11.0 was no sound, there may be also programs that took advantage of the unsoundness, but then refusing them is certainly correct.