[GHC] #7696: Another kindFunResult panic
#7696: Another kindFunResult panic -----------------------------+---------------------------------------------- Reporter: nwf | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 7.6.2 | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: None/Unknown | Blockedby: Blocking: | Related: -----------------------------+---------------------------------------------- While working at the GHCi prompt, I left off a pair of parens, yielding: {{{
import Control.Applicative import Control.Monad.Trans :type \x -> (either (fmap Right) id) <$> lift $ x ghc: panic! (the 'impossible' happened) (GHC version 7.7.20130214 for x86_64-unknown-linux): kindFunResult <<details unavailable>>
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} Replacing `<$> lift $ x` with `<$> (lift $ x)`, which is what I'd meant, makes everybody happier. But as this happens in both 7.6.2 and 7.7.20130214, I thought I should do what it says and report it. Thanks! -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7696> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler
#7696: Another kindFunResult panic -----------------------------+---------------------------------------------- Reporter: nwf | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 7.6.2 | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: None/Unknown | Blockedby: Blocking: | Related: -----------------------------+---------------------------------------------- Comment(by monoidal): There are two different issues here: one causes panic in HEAD, the other in 7.6.2. Panic in HEAD (7.6 correctly reports error): {{{ f1 :: (m a, t m) f1 = undefined f2 :: ((), m ()) f2 = f1 }}} Panic in 7.6 (HEAD correctly reports error): {{{ lift :: m a -> t m a lift = undefined k :: f (Either Int Int) k = lift }}} The second one is probably the same cause as #7368, which was left unfixed in 7.6. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7696#comment:1> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler
#7696: Another kindFunResult panic -----------------------------+---------------------------------------------- Reporter: nwf | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 7.6.2 | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: None/Unknown | Blockedby: Blocking: | Related: -----------------------------+---------------------------------------------- Comment(by simonpj@…): commit c969cc3d2cfcd31fc8e7222c7c9ec116191c136b {{{ Author: Simon Peyton Jones <simonpj@microsoft.com> Date: Sun Mar 3 23:04:09 2013 +0000 Treat equalities with incompatible kinds as "irreducible" constraints Originally we had the invariant that CTyEqCan and CFunEqCan have LHS and RHS with compatible kinds. This is important because if they have different kinds, then a substitution using the CTyEqCan can give rise to an ill-kinded type, which in turn makes typeKind crash, and this led to Trac #7696. (The possibility of this happening really only occurred when we introduced kind polymorphism.) I thought at first this was going to be really awkward to solve, but happily it turned out to be easy. We already have CIrredEvCan constraints, which are "stuck"; we can't use them and we can't solve them. Yet. After some substitution from solving other constraints we may be able to make progress. So for equality constraints where the LHS and RHS don't have compatible kinds (although perhaps not YET compatible, eg k and *, just needing to unify k := *), we now generate a CIrredEvCan, plus the necessary kind equality constraint. This entailed some refactoring of course, but only in TcCanonical. In particular, the emitKindConstraint code has gone, in favour of a kind check in canEqLeaf. See Note [Equalities with incompatible kinds] in TcCanonical, and Note [CIrredEvCan constraints] in TcRnTypes compiler/typecheck/TcCanonical.lhs | 150 +++++++++++++++++++----------------- compiler/typecheck/TcRnTypes.lhs | 33 ++++++-- 2 files changed, 102 insertions(+), 81 deletions(-) }}} -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7696#comment:2> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler
#7696: Another kindFunResult panic ------------------------------------------+--------------------------------- Reporter: nwf | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.6.2 Resolution: fixed | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: None/Unknown | Difficulty: Unknown Testcase: typecheck/should_fail/T7696 | Blockedby: Blocking: | Related: ------------------------------------------+--------------------------------- Changes (by simonpj): * cc: dimitris@… (added) * difficulty: => Unknown * status: new => closed * resolution: => fixed * testcase: => typecheck/should_fail/T7696 Comment: Excellent point! Actually this bug revealed a pretty significant shortcoming in the constraint solver (see the commit message). Fortunately, I found rather a neat solution, so all is good now. Thanks for identifying it so compactly. Simon -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7696#comment:3> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler
participants (1)
-
GHC