Opened 3 years ago

Closed 22 months 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 Revisions:

Description

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 3 years ago by simonpj@…

commit 969f8b728be0a2fec8263e8866295776c993394b

Author: Simon Peyton Jones <[email protected]>
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 3 years ago by simonpj

  • difficulty set to Unknown
  • Resolution set to fixed
  • Status changed from new to closed
  • Test Case set to polykinds/T6068

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

Simon

comment:3 Changed 22 months ago by nomeata

  • Cc hvr added
  • Resolution fixed deleted
  • Status changed from closed to new

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 >T6068.run.stdout 2>T6068.run.stderr
Actual stderr output differs from expected:
--- /dev/null	2013-11-12 10:20:30.826690103 +0100
+++ ./polykinds/T6068.run.stderr	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:  http://www.haskell.org/ghc/reportabug
+
Actual stdout output differs from expected:
--- ./polykinds/T6068.stdout	2013-10-05 15:18:57.118579683 +0200
+++ ./polykinds/T6068.run.stdout	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 22 months 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 22 months 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 22 months ago by nomeata (previous) (diff)

comment:6 Changed 22 months ago by simonpj

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

comment:7 Changed 22 months 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 22 months 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.

Simon

comment:9 Changed 22 months 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 22 months ago by simonpj

  • Resolution set to fixed
  • Status changed from new to closed

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.

Simon

Note: See TracTickets for help on using tickets.