#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