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: 7298 Reporter:@lpw25 Assigned to:@garrigue Status: resolved (set by @garrigue on 2016-10-20T02:27:46Z) Resolution: fixed Priority: normal Severity: minor Version: 4.04.0 +dev / +beta1 / +beta2 Target version: 4.05.0 +dev/beta1/beta2/beta3/rc1 Fixed in version: 4.04.0 +dev / +beta1 / +beta2 Category: typing Related to:#7381
Bug description
The following code fails to type-check:
type t = T : t
module M : sig
type free = < bar : t -> unit; foo : free -> unit >
end = struct
class free = object (self : 'self)
method foo self = ()
method bar T =
self#foo self
end
end
with the error:
Error: Signature mismatch:
...
Type declarations do not match:
type free =
< bar : t -> unit;
foo : (< bar : t -> unit; foo : 'a -> unit > as 'a) -> unit >
is not included in
type free = < bar : t -> unit; foo : free -> unit >
but if we use non-GADT syntax for the definition of [T] then there is no error.
I'm not sure how exactly it is happening, but the issue is that one of the dummy_method fields is being duplicated and allowed to escape from the class definition.
(This is similar to #7293 but different as this bug is still present on trunk)
The text was updated successfully, but these errors were encountered:
This one is a but different.
The dummy method does not escape, it is only believed to escape: i.e. the logic in update_level used to check that the type of self does not escape is wrongly activated.
Would probably need to find a different way to check that.
Bu this is not high priority as the number of features required to cause this (completeness) problem is large (GADTs + binary methods).
The dummy method does not escape, it is only believed to escape: i.e. the logic in update_level used to check that the type of self does not escape is wrongly activated.
I'm slightly confused by this. When the module inclusion check is done -- so after the escape logic has been run -- the internal free type still contains a dummy method, and that is what causes the inclusion check to fail. Am I misunderstanding something, or did it behave differently when you ran it?
Bu this is not high priority as the number of features required to cause this (completeness) problem is large (GADTs + binary methods).
The reason I came across this bug is that I am trying to evaluate turning on GADT-style matching for all matches that contain a variant constructor, rather than just those matches that obviously contain a GADT. This would allow disambiguation of GADTs in pattern matching (of course it may have too much of a compile-time performance cost, but that is what I was trying to evaluate). In that context, this bug becomes a bit of a show stopper as it basically happens for any binary method.
OK, merging GADT matching with normal case is indeed a goal.
But I think that a first step would be to get rid of all the hackery in type_cases.
This mechanism of synchronization between ids and levels is weird.
Same thing for the dummy method: the current approach is too brittle.
Have to understand better how it works.
Original bug ID: 7298
Reporter: @lpw25
Assigned to: @garrigue
Status: resolved (set by @garrigue on 2016-10-20T02:27:46Z)
Resolution: fixed
Priority: normal
Severity: minor
Version: 4.04.0 +dev / +beta1 / +beta2
Target version: 4.05.0 +dev/beta1/beta2/beta3/rc1
Fixed in version: 4.04.0 +dev / +beta1 / +beta2
Category: typing
Related to: #7381
Bug description
The following code fails to type-check:
type t = T : t
module M : sig
type free = < bar : t -> unit; foo : free -> unit >
end = struct
end
with the error:
Error: Signature mismatch:
...
Type declarations do not match:
type free =
< bar : t -> unit;
foo : (< bar : t -> unit; foo : 'a -> unit > as 'a) -> unit >
is not included in
type free = < bar : t -> unit; foo : free -> unit >
but if we use non-GADT syntax for the definition of [T] then there is no error.
I'm not sure how exactly it is happening, but the issue is that one of the dummy_method fields is being duplicated and allowed to escape from the class definition.
(This is similar to #7293 but different as this bug is still present on trunk)
The text was updated successfully, but these errors were encountered: