Re: [GHC] #8467: Stack overflow when optimizing recursive newtype

#8467: Stack overflow when optimizing recursive newtype -------------------------------------------------+------------------------- Reporter: goldfire | Owner: Type: bug | Status: Priority: normal | closed Component: Compiler | Milestone: Resolution: fixed | Version: 7.7 Operating System: Unknown/Multiple | Keywords: Type of failure: None/Unknown | Architecture: Test Case: stranal/should_compile/T8467 | Unknown/Multiple Blocking: | Difficulty: | Unknown | Blocked By: | Related Tickets: -------------------------------------------------+------------------------- Comment (by Simon Peyton Jones ): In [changeset:"2650da2b8b744248c2529d8c5969b78cd97239d3/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="2650da2b8b744248c2529d8c5969b78cd97239d3" Refactor the topNormaliseNewType story, fixing Trac #8467 A bit of a mess had accumulated, with unclear invariants. * Remove splitNewTypeRepCo_maybe, in favour of topNormaliseNewType_maybe (which had the same signature but behaved subtly differently). * Make topNormaliseNewType_maybe guaranteed to return a non-newtype if it says (Just ty). This is what was causing the loop in #8467 * Apply similar tidying up to FamInstEnv.topNormaliseType }}} -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8467#comment:3 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler