Opened 7 years ago

Closed 6 years ago

#6068 closed bug (fixed)

Panic in GHCi when using functional dependencies and promoted kinds

Reported by: goldfire Owned by:
Priority: normal Milestone:
Component: GHCi Version: 7.5
Keywords: PolyKinds Cc: hvr, goldfire
Operating System: Unknown/Multiple Architecture: Unknown/Multiple
Type of failure: GHCi crash Test Case: polykinds/T6068
Blocked By: Blocking:
Related Tickets: Differential Rev(s):
Wiki Page:


Consider the following code:

{-# LANGUAGE PolyKinds, DataKinds, TypeFamilies, GADTs, MultiParamTypeClasses,
             FunctionalDependencies, FlexibleInstances, UndecidableInstances #-}

import Prelude hiding (Maybe, Nothing)

data Maybe :: * -> * where
  Nothing :: Maybe a

data family Sing (a :: k)

data instance Sing (a :: Maybe k) where
  SNothing :: Sing Nothing

data KProxy (a :: *) = KProxy
data Existential (p :: KProxy k) =
  forall (a :: k). Exists (Sing a)

class HasSingleton a (kp :: KProxy k) | a -> kp where
  exists :: a -> Existential kp

instance forall a (mp :: KProxy (Maybe ak)). HasSingleton (Maybe a) mp where
  exists Nothing = Exists SNothing

When I load it into GHCi and ask for

*Main> :t exists Nothing

I get the following:

ghc-stage2: panic! (the 'impossible' happened)
  (GHC version 7.5.20120426 for x86_64-apple-darwin):
	tcTyVarDetails ak{tv avTW} [tv]

When I add foo = exists Nothing to the end of the compiled code, however, the behavior is as expected. I did try adding all relevant GHC extensions to the running instance of GHCi, but that did not solve the problem.

Change History (10)

comment:1 Changed 7 years ago by simonpj@…

commit 969f8b728be0a2fec8263e8866295776c993394b

Author: Simon Peyton Jones <>
Date:   Wed May 16 11:13:52 2012 +0100

    Be careful to instantiate kind variables when dealing with functional dependencies
    There were really two bugs
      a) When the fundep fires we must apply the matching
         substitution to the kinds of the remaining type vars
         (This happens in FunDeps.checkClsFD, when we create meta_tvs)
      b) When instantiating the un-matched type variables we must
         instantiate their kinds properly
         (This happens in TcSMonad.instFlexiTcS)
    This fixes #6068 and #6015 (second reported bug).

 compiler/typecheck/TcInteract.lhs |    6 +--
 compiler/typecheck/TcSMonad.lhs   |    8 +++-
 compiler/types/FunDeps.lhs        |   87 ++++++++++++++++++++++---------------
 3 files changed, 60 insertions(+), 41 deletions(-)

comment:2 Changed 7 years ago by simonpj

difficulty: Unknown
Resolution: fixed
Status: newclosed
Test Case: polykinds/T6068

I believe this patch fixes the bug. Thanks for reporting it with a nice small test case. Give it a try


comment:3 Changed 6 years ago by nomeata

Cc: hvr added
Resolution: fixed
Status: closednew

In a fresh checkout (95216e8fa0ecb98189dce29f0b89b3b0f8d439c6, distclean’ed and built), I get:

=====> T6068(ghci) 2026 of 3814 [0, 0, 0] 
cd ./polykinds && HC='/home/jojo/build/haskell/ghc/inplace/bin/ghc-stage2' HC_OPTS='-dcore-lint -dcmm-lint -dno-debug-output -no-user-package-db -rtsopts -fno-ghci-history ' '/home/jojo/build/haskell/ghc/inplace/bin/ghc-stage2' --interactive -v0 -ignore-dot-ghci -dcore-lint -dcmm-lint -dno-debug-output -no-user-package-db -rtsopts -fno-ghci-history     <T6068.script > 2>
Actual stderr output differs from expected:
--- /dev/null	2013-11-12 10:20:30.826690103 +0100
+++ ./polykinds/	2013-11-12 10:39:54.333361005 +0100
@@ -0,0 +1,9 @@
+ghc-stage2: panic! (the 'impossible' happened)
+  (GHC version 7.7.20131108 for x86_64-unknown-linux):
+	ASSERT failed!
+    file compiler/typecheck/TcMType.lhs line 809
+    [D] _ :: mp{tv aEn} [tau[0]]
+             ghc-prim:GHC.Types.~{(w) tc 31Q} kp_aEi{tv} [tau[0]] (CIrredEvCan)
+Please report this as a GHC bug:
Actual stdout output differs from expected:
--- ./polykinds/T6068.stdout	2013-10-05 15:18:57.118579683 +0200
+++ ./polykinds/	2013-11-12 10:39:54.193361010 +0100
@@ -1 +0,0 @@
-exists Nothing :: Floop a mp => Existential mp
*** unexpected failure for T6068(ghci)

Strangely, on travis it succeeded.

comment:4 Changed 6 years ago by nomeata

With completely fresh check-outs, it does not happen using validate, but it does happen with BuildFlavour = devel2. So likely it is related to -DDebug in GhcStage2HcOpts.

comment:5 Changed 6 years ago by nomeata

Confirmed, the test fails with -DDEBUG, but not without. So is the debugging information wrong, or is there a real bug?

Last edited 6 years ago by nomeata (previous) (diff)

comment:6 Changed 6 years ago by simonpj

I think there's a real bug. I'm looking at it

comment:7 Changed 6 years ago by Simon Peyton Jones <simonpj@…>

In dff0e99d37f3529041bb2bb66ffda1ea22af14e0/ghc:

Fix a subtle bug in kind-mis-matched equalities (Trac #6068)

When we have an equality constraint where the LHS and RHS
have ill-matched kinds, it get turned into a CIrredEvCan
because a CTyEqCan/CFunEqCan are guaranteed kind-compatible.

But that in turn led to a bug because in the constraint
    c  =  (a:k1) ~ (b:k2)
the kind variables k1 and k2 don't show up in tyVarsOfType c.
Why not?  Because it looks like
    (~) k1 (a:k1) (b:k2)
Maybe (~) should have two kind arguments?  That seemed
like too big a change for not (we wait for NoKinds), so
this patch fixes the bug for now.

comment:8 Changed 6 years ago by simonpj

Cc: goldfire added

Tanks for pointing out this crash. As the comments show (Note [Kicking out Irreds] in TcInteract), it raises an interesting point.


comment:9 Changed 6 years ago by Simon Peyton Jones <simonpj@…>

In 1e0ef8265d67d05e5114310311804b6d51bec7dd/ghc:

Fix canIrredPred again

This follows up the earlier patch to Trac #6068, which I
obviously hadn't validated properly.

comment:10 Changed 6 years ago by simonpj

Resolution: fixed
Status: newclosed

The bug showed up because you ran the testsuite with a compiler built with -DDEBUG. This is a good thing to do. Although there was a real bug, I couldn't come up with a way to tickle it without the -DDEBUG to flush it out, so I'm just closing. Thanks for alerting me to htis.


Note: See TracTickets for help on using tickets.