Re: [GHC] #16038: Simplifier incorrectly breaks recursive groups

19 Dec 2018

      #16038: Simplifier incorrectly breaks recursive groups
-------------------------------------+-------------------------------------
        Reporter:  osa1              |                Owner:  osa1
            Type:  bug               |               Status:  new
        Priority:  highest           |            Milestone:
       Component:  Compiler          |              Version:  8.6.3
      Resolution:                    |             Keywords:
Operating System:  Unknown/Multiple  |         Architecture:
                                     |  Unknown/Multiple
 Type of failure:  None/Unknown      |            Test Case:
      Blocked By:                    |             Blocking:
 Related Tickets:                    |  Differential Rev(s):
       Wiki Page:                    |
-------------------------------------+-------------------------------------

Comment (by osa1):

 I think what's happening is this: in the boot file we're declaring a
 dictionary
 for `Eq i => Eq (HsExpr i)` without saying anything about the
 implementation.

 In `B.hs` we then refer to this dictionary in `Eq i => Eq (HsOverLit i)`
 because
 `HsOverLit` refers to `HsExpr`.

 At this point there isn't a loop yet because we don't know that `HsExpr`
 will be
 referring to `HsOverLit`.

 Then in A.hs we define `HsExpr` with a reference to `HsOverLit`. The
 dictionary
 definitions are now recursive but in the current module there's no way to
 see
 that. At this point if we don't do any inlining we'll still have a
 recursive
 group, but functions in the group will be living in different object
 files. I
 don't know if this is something we support. Maybe this is also a problem.

 If we inline `Eq (HsExpr i) => Eq (HsOverLit i)` and its methods then we
 get a
 recursive group in `A.hs`, but I guess we don't do "glomming" in the right
 places and don't realize this.

 So I think we may have two problems here:

 - Without any inlining we get a recursive group where functions live in
   different object files. Is this something we support?
 - With inlining we don't realize that after inlining we make new recursive
   groups (previously non-recursive definitions become recursive). This
 seems to
   be a problem with "glomming", and the same thing should be happening
 with
   RULEs too. I'll read the relevant code for RULEs to see how this is
 handled
   for RULEs.

 One hacky thing I tried was to do glomming always in `occurAnalyzePgm`,
 but that
 didn't fix it.

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