Re: [GHC] #13481: T12622 fails in ghci way

3 Sep 2017

      #13481: T12622 fails in ghci way
-------------------------------------+-------------------------------------
        Reporter:  bgamari           |                Owner:  bgamari
            Type:  bug               |               Status:  new
        Priority:  high              |            Milestone:  8.2.2
       Component:  Compiler          |              Version:  8.1
      Resolution:                    |             Keywords:
                                     |  StaticPointers
Operating System:  Unknown/Multiple  |         Architecture:
 Type of failure:  Compile-time      |  Unknown/Multiple
  crash or panic                     |            Test Case:  T12622
      Blocked By:                    |             Blocking:
 Related Tickets:  #12622, #12356    |  Differential Rev(s):
       Wiki Page:                    |
-------------------------------------+-------------------------------------

Comment (by bgamari):

 It looks like the cause here is that we started out with,
 {{{#!hs
 main :: IO ()
 [LclIdX]
 main
   = break<14>()
     let {
       s_a2kk :: StaticPtr (Bool -> Bool)
       [LclId]
       s_a2kk = ...
     } in
     break<13>(s_a2kk)
     >>=
       @ IO
       GHC.Base.$fMonadIO
       @ (Bool -> Bool)
       @ ()
       (break<10>(s_a2kk) lookupKey @ (Bool -> Bool) s_a2kk)
       (...)

 }}}

 But then `FloatOut` floats `s_a2kk` out of the let giving it a new name
 (`s_s3Sy`) in the process. Somehow `main` then gets partially rewritten
 to,
 {{{#!hs
 main :: IO ()
 [LclIdX]
 main
   = break<14>()
     break<13>(s_s3Sy)
     >>=
       @ IO
       $fMonadIO
       @ (Bool -> Bool)
       @ ()
       (break<10>(s_a2kk) lvl_s3Sz)
       lvl_s3SA
 }}}

 Note the mention of `s_a2kk` remaining in `break<10>`, despite the fact
 that the reference in `break<13>` was correctly renamed.

-- 
Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/13481#comment:8
GHC http://www.haskell.org/ghc/
The Glasgow Haskell Compiler