#7354 closed bug (fixed)

Panic with recursion-schemes package and unit

Reported by: amplitwist Owned by:
Priority: normal Milestone:
Component: GHCi Version: 7.6.1
Keywords: Cc:
Operating System: Linux Architecture: x86_64 (amd64)
Type of failure: GHCi crash Difficulty: Unknown
Test Case: indexed_types/T7354a, T7354b Blocked By:
Blocking: Related Tickets:

Description (last modified by simonpj)

Steps to reproduce:

  1. Install GHC 7.6.1 and recursion-schemes (http://hackage.haskell.org/package/recursion-schemes)
  2. Create a new .hs file with the following
    import Data.Functor.Foldable
    
    foo = embed ()
    
  3. Load the file into GHCI
  4. Evaluate foo
    *Main> foo
    
    <interactive>:162:1:
        Can't find interface-file declaration for variable foo
          Probable cause: bug in .hi-boot file, or inconsistent .hi file
          Use -ddump-if-trace to get an idea of which file caused the error
        In the expression: foo
        In an equation for `it': it = foo
    *Main> :t foo
    
    <interactive>:1:1:
        Can't find interface-file declaration for variable foo
          Probable cause: bug in .hi-boot file, or inconsistent .hi file
          Use -ddump-if-trace to get an idea of which file caused the error
        In the expression: foo
    
  5. Evaluate `embed ()' directly at the REPL
    *Main> embed ()
    ghc: panic! (the 'impossible' happened)
      (GHC version 7.6.1 for x86_64-unknown-linux):
    	nameModule
    <<details unavailable>>
    

System Information:

[andy@vanir ~]$ uname -a
Linux vanir 3.5.6-1-ARCH #1 SMP PREEMPT Sun Oct 7 19:30:49 CEST 2012 x86_64 GNU/Linux
[andy@vanir ~]$ ls asdf.hi # the would-be .hi file
ls: cannot access asdf.hi: No such file or directory

Change History (8)

comment:1 Changed 18 months ago by guest

I reduced your testcase:

  1. Create file T.hs
{-# LANGUAGE TypeFamilies, FlexibleContexts #-}
module T where

type family Base t :: * -> *

class Unfoldable t where
  embed :: Base t t -> t
  1. Create file R.hs
module R where

import T
foo = embed ()
  1. Run ghci R.hs, and observe
    *R> foo
    
    <interactive>:2:1:
        Can't find interface-file declaration for variable foo
          Probable cause: bug in .hi-boot file, or inconsistent .hi file
          Use -ddump-if-trace to get an idea of which file caused the error
        In the expression: foo
        In an equation for `it': it = foo
    *R> embed ()
    ghc: panic! (the 'impossible' happened)
      (GHC version 7.6.1 for x86_64-unknown-linux):
    	nameModule
    <<details unavailable>>
    
    Please report this as a GHC bug:  http://www.haskell.org/ghc/reportabug
    

comment:2 Changed 18 months ago by amplitwist

Here's another test case.

{-# LANGUAGE CPP, TypeFamilies, Rank2Types, FlexibleContexts, FlexibleInstances, GADTs, StandaloneDeriving, UndecidableInstances #-}

module Main where

type family Base t :: * -> *
data family Prim t :: * -> *

class Functor (Base t) => Unfoldable t where
  embed :: Base t t -> t
  ana
    :: (a -> Base t a) -- ^ a (Base t)-coalgebra
    -> a               -- ^ seed
    -> t               -- ^ resulting fixed point
  ana g = a where a = embed . fmap a . g


data instance Prim [a] b = Cons a b | Nil deriving (Eq,Ord,Show,Read)

coalg 0 = Nil
coalg n = Cons n (n-1)
alg Nil = 1
alg (Cons a b) = a * b

instance Functor (Prim [a]) where
  fmap f (Cons a b) = Cons a (f b)
  fmap _ Nil = Nil

Load into GHCI, and evaluate:

*Main> ana alg
ghc: panic! (the 'impossible' happened)
  (GHC version 7.6.1 for x86_64-unknown-linux):
	nameModule
<<details unavailable>>

Please report this as a GHC bug:  http://www.haskell.org/ghc/reportabug

comment:3 Changed 18 months ago by simonpj

  • Description modified (diff)
  • Difficulty set to Unknown

Right. I can reproduce this failure with 7.6.1. Happily HEAD says:

$ ~/5builds/HEAD/inplace/bin/ghc-stage2 --interactive T7354.hs
GHCi, version 7.7: http://www.haskell.org/ghc/  :? for help
Loading package ghc-prim ... linking ... done.
Loading package integer-gmp ... linking ... done.
Loading package base ... linking ... done.
[1 of 1] Compiling T7354            ( T7354.hs, interpreted )
Ok, modules loaded: T7354.
*T7354> ana alg

<interactive>:2:5:
    Occurs check: cannot construct the infinite type:
      a ~ Base t (Prim [a] a)
    Expected type: Prim [a] a -> Base t (Prim [a] a)
      Actual type: Prim [a] a -> a
    Relevant bindings include
      it :: Prim [a] a -> t (bound at <interactive>:2:1)
    In the first argument of `ana', namely `alg'
    In the expression: ana alg
    In an equation for `it': it = ana alg

which looks right.

Next is to try recursion-schemes with HEAD.

comment:4 Changed 18 months ago by simonpj

In the T/R example from comment 1, we get

R.hs:4:13:
    Couldn't match expected type `Base t t' with actual type `()'
    Relevant bindings include foo :: t (bound at R.hs:4:1)
    In the first argument of `embed', namely `()'
    In the expression: embed ()
    In an equation for `foo': foo = embed ()

comment:5 Changed 18 months ago by simonpj

  • Test Case set to indexed_types/T7354a, T7354b

So the bug looks as if it's fixed in HEAD, but I've been doing lots of stuff in HEAD over the last couple of months and am not keen on repeating that in 7.6, esp because I am totally swamped at the moment.

Proposal: leave it un-fixed in 7.6 and ask you to use HEAD. How bad is that? I think this only bites when you have a type error; it doesn't prevent you using recursion-schemes.

Simon

comment:6 Changed 18 months ago by amplitwist

OK, that'll do. Good to see it's fixed in HEAD.

comment:7 Changed 15 months ago by shachaf

For what it's worth, elliott in #haskell came across this bug in a different context. Here are two simpler cases (7.6.1):

  • Panics:
type family T :: * -> *
x :: ()
x = undefined :: T a
  • Doesn't panic, but type-checks when it shouldn't:
type family T :: * -> *
x :: ()
x = undefined :: (b ~ T a) => b

Note that if you make an instance of T (e.g. newtype Id a = Id a; type instance T = Id), then even uses of Id unrelated to x cause a panic, as long as x exists.

-dcore-lint catches the first case before it gets to a "real" panic. None of this is problematic in HEAD.

Note: I haven't managed to get unsafeCoerce out of this, but that doesn't mean it's impossible. It's important to keep in mind that in the presence of SafeHaskell, type checker bugs can have security implications. Maybe -XSafe should imply/suggest -dcore-lint, or something along those lines? That's come up in a few other places, like #7453. Using SafeHaskell safely should be as easy as possible, not rely on obscure folklore and "compiler debugging options".

comment:8 Changed 15 months ago by simonpj

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

OK well, I'll close this ticket as fixed, because it is, and we have a regression test. You make a separate suggestion about Safe Haskell; doing -dcore-lint when compiling with Safe Haskell would be a good belt-and-braces move. But it's one for a separate ticket, if you want to open one. (And discuss with David Terei, of course.)

Simon

Note: See TracTickets for help on using tickets.