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

type inference for inheritance is broken in OCaml 4.07 #7865

Open
vicuna opened this Issue Oct 20, 2018 · 4 comments

Comments

Projects
None yet
3 participants
@vicuna
Copy link
Collaborator

vicuna commented Oct 20, 2018

Original bug ID: 7865
Reporter: slindley
Assigned to: @trefis
Status: assigned (set by @trefis on 2018-10-22T13:04:17Z)
Resolution: open
Priority: high
Severity: major
Version: 4.07.0
Category: typing
Monitored by: @nojb @hcarty

Bug description

Attempting to compile the following code

class c =
object (o)
  method foo = o
end

class d =
object (o) inherit c
  method bar = fun () ->
    let o = List.fold_right (fun _ o -> o#foo) [] o in
    let o = match [] with | [] -> o in o
end

leads to the error

File "bug.ml", line 10, characters 34-35:
Error: This expression has type < bar : unit -> 'b; foo : 'a; .. > as 'a
       but an expression was expected of type 'c
       Self type cannot escape its class

The problem can be worked around by adding type annotations:

class d =
object (o : 'self) inherit c
  method bar = fun () ->
    let o = List.fold_right (fun _ o -> o#foo) [] o in
    let (o : 'self) = match [] with | [] -> o in o
end

Additional information

In the context of a much larger program (the Links web programming language), we managed to make the compiler crash (even with the type annotation) by invoking another method in the body of the match:

links-lang/links#407

It probably wouldn't be too hard to generate a small example for that bug too, but I'm hopeful that fixing the initial typing problem may also fix the compiler crash.

@vicuna

This comment has been minimized.

Copy link
Collaborator Author

vicuna commented Oct 22, 2018

Comment author: @trefis

I could indeed reproduce on 4.07 but neither on previous versions, nor on trunk.

Note that one needs to pattern-match on a variant type to be able to get the error message on 4.07, if one uses an other construct (e.g. an if) or matches on a string, everything works fine.

It seems that #1735 ( #1735 ) fixed the issue, at least for the small reproduction case available on this MPR. I haven't looked into the details of what was going wrong and how this change could have fixed it yet however.

The uncaught exception that you mention looks like it might be yet another issue, and I will try to look into it further in a couple of days.

@vicuna

This comment has been minimized.

Copy link
Collaborator Author

vicuna commented Nov 26, 2018

Comment author: frank-emrich

Just to confirm that the compiler exception we were seeing in the context of this bug has been resolved in trunk, too.

@alainfrisch

This comment has been minimized.

Copy link
Contributor

alainfrisch commented Mar 20, 2019

Ping @lpw25, since the example in this PR might give an interesting test case for your big overhaul of class type-checking #8516. Anyway, since the bug appeared in 4.07 and then disappeared without a dedicated fix for it, it would be worth adding an explicit non-regression test.

@trefis

This comment has been minimized.

Copy link
Contributor

trefis commented Mar 20, 2019

Anyway, since the bug appeared in 4.07 and then disappeared without a dedicated fix for it, it would be worth adding an explicit non-regression test.

Fair point, I'm reopening until this is done.

@trefis trefis reopened this Mar 20, 2019

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.