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
-principal causes loop in type checker when compiling #7305
Comments
Comment author: @avsm More details at ocsigen/js_of_ocaml#503 |
Comment author: @avsm Confirmed to only happen on 4.03.0 and not on 4.02.3 |
Comment author: @garrigue Is it possible to get a reduction of this bug? Debugging the typer on code involving large libraries is extremely painful. |
Comment author: @mshinwell Leo will investigate making a smaller reproduction case. |
Comment author: @lpw25 This seems to be caused by the fix for #5663. I haven't been able to pin down the exact cause, so I don't have a small reproduction case, but essentially the change for #5663 introduced expansion of type constructors when checking if a compilations unit's type was closed or not. Doing expansion creates fresh types, which is why the check can loop forever. It normally doesn't because of the memoization of expansion, but that is not completely reliable so I don't think it is a good idea for the correctness of this function to depend on it. This explains the difference between with -principal and without, since principal does less memoization of type expansion. Although even without -principal this check is very expensive on the large class types used in js_of_ocaml -- and seems completely unnecessary since the original type is something like: string -> Dom.html_element Js.t which is trivially closed. |
Comment author: @garrigue I have created a pull request with a fix. Leo, could you check that it indeed solves the problem? Note that the fact it doesn't stop is disturbing, because memoization of expansions should be reliable (the correctness of the type checker relies on it). So there may be a deeper bug somewhere. |
Comment author: @garrigue By the way, this is a new example of a bug that could have been found early on if we had a way of tracking changes in execution performance of the compiler. |
Comment author: @lpw25
Interesting, I had always assumed it was just an optimisation. Having investigated further, I think that the code is not actually in an infinite loop. I think the algorithm is just exponential nested structural types. Which leads me to the following reproduction case: type t1 = type t2 = type t3 = type t4 = type t5 = type t6 = type t7 = type t8 = let x : t8 list = [] The compiler is killed by the kernel for using too much memory when I try to compile this file with |
Comment author: @garrigue Fixed in 4.04 by commit b65078c. Note that I only checked the effect by a small reduction test, pr7305_principal.ml: let x = ref ([] : c7 list) |
Original bug ID: 7305
Reporter: @avsm
Assigned to: @garrigue
Status: closed (set by @xavierleroy on 2017-09-24T15:33:17Z)
Resolution: fixed
Priority: normal
Severity: crash
Version: 4.03.0
Fixed in version: 4.04.0 +dev / +beta1 / +beta2
Category: typing
Bug description
When compiling Cohttp (which uses -principal, but several of its dependent libraries do not), the type checker goes into an infinite loop:
It compiles fine when -principal is removed
Steps to reproduce
opam install js_of_ocaml cohttp
opam source cohttp
cd
make TESTS=--enable-tests
lldb ocamlc.optprocess launch -- -verbose -principal -I /Users/avsm/.opam/system/lib/bytes -I /Users/avsm/.opam/system/lib/js_of_ocaml -I /Users/avsm/.opam/system/lib/lwt -I /Users/avsm/.opam/system/lib/stringext -I /Users/avsm/.opam/system/lib/sexplib -I /Users/avsm/.opam/system/lib/re -I /Users/avsm/.opam/system/lib/uri -I /Users/avsm/.opam/system/lib/fieldslib -I /Users/avsm/.opam/system/lib/base64 -I /Users/avsm/.opam/system/lib/cohttp -ppx /Users/avsm/.opam/system/lib/js_of_ocaml/./ppx_js -ppx ppx_lwt lib_test/test_xhr.ml
The text was updated successfully, but these errors were encountered: