Skip to content

GitLab

  • Projects
  • Groups
  • Snippets
  • Help
    • Loading...
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
  • Sign in / Register
GHC
GHC
  • Project overview
    • Project overview
    • Details
    • Activity
    • Releases
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
    • Locked Files
  • Issues 4,274
    • Issues 4,274
    • List
    • Boards
    • Labels
    • Service Desk
    • Milestones
    • Iterations
  • Merge Requests 412
    • Merge Requests 412
  • Requirements
    • Requirements
    • List
  • CI / CD
    • CI / CD
    • Pipelines
    • Jobs
    • Schedules
  • Security & Compliance
    • Security & Compliance
    • Dependency List
    • License Compliance
  • Operations
    • Operations
    • Incidents
    • Environments
  • Analytics
    • Analytics
    • CI / CD
    • Code Review
    • Insights
    • Issue
    • Repository
    • Value Stream
  • Wiki
    • Wiki
  • Snippets
    • Snippets
  • Members
    • Members
  • Collapse sidebar
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
  • Glasgow Haskell Compiler
  • GHCGHC
  • Issues
  • #9235

Closed
Open
Opened Jun 24, 2014 by klao@trac-klao

Simplifier ticks exhausted on recursive class method

GHC 7.8 and HEAD panic on the following code:

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?

Trac metadata
Trac field Value
Version 7.8.2
Type Bug
TypeOfFailure OtherFailure
Priority normal
Resolution Unresolved
Component Compiler
Test case
Differential revisions
BlockedBy
Related
Blocking
CC
Operating system
Architecture
Assignee
Assign to
⊥
Milestone
⊥
Assign milestone
Time tracking
None
Due date
None
Reference: ghc/ghc#9235