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: 6510 Reporter:@alainfrisch Assigned to:@lpw25 Status: closed (set by @xavierleroy on 2016-12-07T10:34:26Z) Resolution: fixed Priority: low Severity: minor Fixed in version: 4.02.0+dev Category: typing Monitored by:@gasche
Bug description
There is some logic to drop constructors of extensible types when they are shadowed by a constructor of the same name later in the structure:
type t = ..;;
type t = ..
module X = struct type t+= A type t+= X type t+= A end;;
module X : sig type t += X type t += A end
Individual constructors can also be dropped from a declaration containing multiple ones:
module X = struct type t+= A|B type t+= X type t+= A end;;
module X : sig type t += B type t += X type t += A end
But because of the way declarations of multiple constructors in a single declaration is encoded in the internal representation of signatures, this can "merge" a constructor with a preceding declaration:
module X = struct type t+= C type t+= A|B type t+= X type t+= A end;;
module X : sig type t += C | B type t += X type t += A end
This can be considered as a bug, since all the logic to keep a structured representation of multiple declarations is there to allow showing signatures that respect the original code. Here the constructors C and B were declared independently but they end up printed together.
But it is even worse, since the same applies if C is added to another type:
type s = ..;;
type s = ..
module X = struct type s+= C type t+= A|B type t+= X type t+= A end;;
module X : sig type s += C | B type t += X type t += A end
Here the printed signature is just plain wrong.
Note: this only applies for inferred signatures. Explicit signatures are probably supported.
I've attached a patch (very lightly tested). I'm still wondering whether using a flat internal representation is the right approach. Leo: do you see major drawbacks in using a more structured representation (closer to the Parsetree/Typedtree structure)?
do you see major drawbacks in using a more structured representation (closer to the Parsetree/Typedtree structure)?
I think that it would make correct handling of ascription harder. In typing terms each extension constructor is a separate element of the module, so almost all code treats them independently. The only place where we care about how they are grouped is in printing.
Original bug ID: 6510
Reporter: @alainfrisch
Assigned to: @lpw25
Status: closed (set by @xavierleroy on 2016-12-07T10:34:26Z)
Resolution: fixed
Priority: low
Severity: minor
Fixed in version: 4.02.0+dev
Category: typing
Monitored by: @gasche
Bug description
There is some logic to drop constructors of extensible types when they are shadowed by a constructor of the same name later in the structure:
type t = ..;;
type t = ..
module X = struct type t+= A type t+= X type t+= A end;;
module X : sig type t += X type t += A end
Individual constructors can also be dropped from a declaration containing multiple ones:
module X = struct type t+= A|B type t+= X type t+= A end;;
module X : sig type t += B type t += X type t += A end
But because of the way declarations of multiple constructors in a single declaration is encoded in the internal representation of signatures, this can "merge" a constructor with a preceding declaration:
module X = struct type t+= C type t+= A|B type t+= X type t+= A end;;
module X : sig type t += C | B type t += X type t += A end
This can be considered as a bug, since all the logic to keep a structured representation of multiple declarations is there to allow showing signatures that respect the original code. Here the constructors C and B were declared independently but they end up printed together.
But it is even worse, since the same applies if C is added to another type:
type s = ..;;
type s = ..
module X = struct type s+= C type t+= A|B type t+= X type t+= A end;;
module X : sig type s += C | B type t += X type t += A end
Here the printed signature is just plain wrong.
Note: this only applies for inferred signatures. Explicit signatures are probably supported.
File attachments
The text was updated successfully, but these errors were encountered: