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

[GHC]

#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 <simonpj@…>):

 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