[GHC] #9235: Simplifier ticks exhausted on recursive class method
GHC
ghc-devs at haskell.org
Tue Jun 24 16:49:55 UTC 2014
#9235: Simplifier ticks exhausted on recursive class method
-----------------------------------+---------------------------------------
Reporter: klao | Owner:
Type: bug | Status: new
Priority: normal | Milestone:
Component: Compiler | Version: 7.8.2
Keywords: | Operating System: Unknown/Multiple
Architecture: | Type of failure: Compile-time crash
Unknown/Multiple | Test Case:
Difficulty: Unknown | Blocking:
Blocked By: |
Related Tickets: |
-----------------------------------+---------------------------------------
GHC 7.8 and HEAD panic on the following code:
{{{#!haskell
module C where
class C a where
c :: C a => a -> Int
c a = c a
{-# INLINE c #-}
instance C ()
x :: Int
x = c ()
}}}
Note that it's the coincidence of the 3 conditions that triggers this bug:
1. the `c` method has to be inlined (explicity or implicitly)
2. it has to be recursive (but, it doesn't have to be as dumbly recursive
as in the example)
3. it has to have this weird, slightly mistaken type signature: `C a => a
-> Int` instead of simply `a -> Int`.
But, when this incidentally happens (in my case, both 2. ''and'' 3. were
unintentional), the user gets a very hard to debug issue. They don't even
get an indication which module is responsible if `c` is used from a
different module than the one with the class definition.
Also note that this happens even with a non-optimized build. And in this
example `c` has to be explicitly marked NOINLINE to prevent it. (In the
instance that I caught in the wild simply removing the INLINE annotation
was enough.)
Finally, on a side note: shouldn't 3. by itself be an error? Or a warning
at least?
--
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9235>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
More information about the ghc-tickets
mailing list