[GHC] #8184: Compiler panic in the presence of cyclic imports

[GHC]

#8184: Compiler panic in the presence of cyclic imports
---------------------------------------+-----------------------------------
        Reporter:  parcs               |            Owner:
            Type:  bug                 |           Status:  new
        Priority:  normal              |        Milestone:
       Component:  Compiler            |          Version:  7.7
      Resolution:                      |         Keywords:
Operating System:  Unknown/Multiple    |     Architecture:
 Type of failure:  Compile-time crash  |  Unknown/Multiple
       Test Case:                      |       Difficulty:  Unknown
        Blocking:  910                 |       Blocked By:
                                       |  Related Tickets:
---------------------------------------+-----------------------------------

Comment (by simonpj):

 Thanks.  I too had a look at this yesterday and I know exactly what's
 going on:

  * When compiling B, the `TyCon` for X (which was built when compiling A)
 has a `DataCon` for X's constructor `X`.  The type of that data con is `Y
 -> X`, but the `Y` is "abstract"; it has no data constructors yet, because
 it too necessarily was built when compiling A.

  * When building the wrapper for `thing` in B, we use the types to drive
 the w/w split.  We unpack X and get a field of type Y, but it's the "old"
 Y.  So `thing` gets only one level of unpacking, despite the rather
 obvious form of its RHS.

  * With `--make`, before compiling C we re-tyepcheck the `TyCons` in the
 module loop (see `GhcMake.reTypecheckLoop`), so now we have the "right" X.
 Then when we construct the wrapper for `thing` we can see the two-level
 unpacking.  Net result: B and C differ on what the wrapper for `thing`
 looks like; disaster.

 If wrappers were exposed as INLINE things just like any other INLINE
 thing, there would be just one source of truth, namely the interface file
 for B.  Currently we try to abbreviate the interface file, by making
 `thing` say "I have a wrapper and its worker is `$wthing`", and the
 importing module constructs the wrapper from that information plus its
 strictness info.  It would actually be simpler not to attempt this
 abbreviation.  Interface files would get a bit bigger, but there would be
 other savings.  I might try that.

-- 
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8184#comment:3>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler