#12593: ghci spins forever -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by Iceland_jack): * Attachment "t5AE.hs" added. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12593> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

#12593: ghci spins forever -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * cc: goldfire (added) Comment: Yes, I can reproduce this with HEAD. It seems that we are updating a unification variable so that it points to itself. I see {{{ Following filled tyvar k_arL[tau:1] = (k_apN[sk] |> Sym U(hole:{arZ}, *, (((k_arR[tau:1] -> k_arU[tau:1] -> TYPE t_arG[tau:1]) -> Constraint) -> (k_arL[tau:1] -> k_arO[tau:1] -> TYPE t_arJ[tau:1]) -> *) -> Constraint)_N) }}} And that is disaster. Remarkable example! -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12593#comment:2> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

#12593: ghci spins forever -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones <simonpj@…>): In [changeset:"66a8c194520aadcaa0482736f3fdd4d2f31a5586/ghc" 66a8c19/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="66a8c194520aadcaa0482736f3fdd4d2f31a5586" Fix a bug in occurs checking 1. Trac #12593 exposed a long-standing bug in the occurs checking machinery. When unifying two type variables a ~ b where a /= b, we were assuming that there could be no occurs-check error. But there can: 'a' can occur in b's kind! When the RHS was a non-tyvar we used occurCheckExpand, which /did/ look in kinds, but not when the RHS was a tyvar. This bug has been lurking ever since TypeInType, maybe longer. And it was present both in TcUnify (the on-the-fly unifier), and in TcInteract. I ended up refactoring both so that the tyvar/tyvar path naturally goes through the same occurs-check as non-tyvar rhss. It's simpler and more robust now. One good thing is that both unifiers now share TcType.swapOverVars TcType.canSolveByUnification previously they had different logic for the same goals 2. Fixing this bug exposed another! In T11635 we end up unifying (alpha :: forall k. k->*) ~ (beta :: forall k. k->*) Now that the occurs check is done for tyvars too, we look inside beta's kind. And then reject the program becuase of the forall inside there. But in fact that forall is fine -- it does not count as impredicative polymoprhism. See Note [Checking for foralls] in TcType. 3. All this fuss around occurrence checking forced me to look at TcUnify.checkTauTvUpdate and TcType.occurCheckExpand There's a lot of duplication there, and I managed to elminate quite a bit of it. For example, checkTauTvUpdate called a local 'defer_me'; and then called occurCheckExpand, which then used a very similar 'fast_check'. Things are better, but there is more to do. }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12593#comment:4> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

#12593: ghci spins forever -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: bug | Status: closed Priority: normal | Milestone: 8.0.2 Component: Compiler | Version: 8.0.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | polykinds/T12593 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed * milestone: => 8.0.2 Comment: Comment:4 merged to `ghc-8.0` as 836f0e248b21c4f802b3dce1593f975296e56ba4. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12593#comment:6> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler