Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Relaxed value restriction broken with principal #7285

Closed
vicuna opened this issue Jul 6, 2016 · 4 comments
Closed

Relaxed value restriction broken with principal #7285

vicuna opened this issue Jul 6, 2016 · 4 comments
Assignees

Comments

@vicuna
Copy link

vicuna commented Jul 6, 2016

Original bug ID: 7285
Reporter: @lpw25
Assigned to: @garrigue
Status: closed (set by @xavierleroy on 2017-09-24T15:33:06Z)
Resolution: fixed
Priority: normal
Severity: minor
Version: 4.03.0
Fixed in version: 4.04.0 +dev / +beta1 / +beta2
Category: typing
Tags: testsuite, typing
Monitored by: @bobzhang @gasche @hcarty

Bug description

In principal mode generalize_structure is used for contravariant variables. However, generalize_structure ignores variables which have already been generalized. This means that instead of generalizing variables which occur only in covariant positions, we generalize any variable which is first encountered in a covariant position.

For example, the following code is allowed and results in a segmentation fault:

      OCaml version 4.03.0

#principal true;;

module M : sig

  type (+'a, -'b) foo
  val apply : ('a, 'b) foo -> 'b -> 'a
  val f : unit -> ('a, 'a) foo
end = struct
  type ('a, 'b) foo = 'b -> 'a
  let apply f x = f x
  let f () =
    let r = ref None in
      fun x ->
        match !r with
        | None -> r := Some x; x
        | Some y -> r := Some x; y
end;;

module M :
sig
type (+'a, -'b) foo
val apply : ('a, 'b) foo -> 'b -> 'a
val f : unit -> ('a, 'a) foo
end

let f = M.f ();;

val f : ('a, 'a) M.foo =

M.apply f 0;;

  • : int = 0

print_endline (M.apply f "World");;

Process ocaml-toplevel segmentation fault (core dumped)

Reversing the order of the type arguments of M.foo gives a type error as expected, since the variable is encountered in a contravariant position first.

@vicuna
Copy link
Author

vicuna commented Jul 6, 2016

Comment author: @gasche

A rather bad bug indeed. (Unlike some other tricky type-system bugs,) I think we could have caught this one with a slightly more proactive testing strategy, testing as much generalization behaviors as possible. Marking the issue as testsuite-related in case people are interested in working on this.

@vicuna
Copy link
Author

vicuna commented Jul 7, 2016

Comment author: @garrigue

Fixed in trunk by commit 9d77b26.

Part of the reason it went undetected is that -principal was not used much until recently.
And I admit that the change to generalize_contravariant was stupid (it should have come with a few tests...)

@vicuna
Copy link
Author

vicuna commented Jul 7, 2016

Comment author: @alainfrisch

it went undetected is that -principal was not used much until recently.

Has something changed recently which makes -principal easier to use, or is it an empirical observation?

@vicuna
Copy link
Author

vicuna commented Jul 7, 2016

Comment author: @garrigue

-principal didn't change, but it is now used for the compiler itself, giving it more visibility.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants