Opened 18 months ago
Closed 15 months ago
#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:
- Install GHC 7.6.1 and recursion-schemes (http://hackage.haskell.org/package/recursion-schemes)
- Create a new .hs file with the following
import Data.Functor.Foldable foo = embed ()
- Load the file into GHCI
- 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
- 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
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
I reduced your testcase: