[GHC] #12063: Knot-tying failure when type-synonym refers to non-existent data

[GHC]

#12063: Knot-tying failure when type-synonym refers to non-existent data
-------------------------------------+-------------------------------------
           Reporter:  ezyang         |             Owner:  ezyang
               Type:  bug            |            Status:  new
           Priority:  normal         |         Milestone:
          Component:  Compiler       |           Version:  8.1
  (Type checker)                     |
           Keywords:  hs-boot        |  Operating System:  Unknown/Multiple
       Architecture:                 |   Type of failure:  None/Unknown
  Unknown/Multiple                   |
          Test Case:                 |        Blocked By:
           Blocking:                 |   Related Tickets:
Differential Rev(s):                 |         Wiki Page:
-------------------------------------+-------------------------------------
 Consider:

 {{{
 -- A.hs-boot
 module A
 data T

 -- B.hs
 module B
 import {-# SOURCE #-} A
 type S = T

 -- A.hs
 module A
 import B
 x :: S
 }}}

 This will cause a tcIfaceGlobal panic when compiling `A.hs` in one-shot
 mode. The reason is that we will attempt to knot tie `B.hi`'s reference to
 `A:T` when typechecking the contents of `A.hs`, but unfortunately there is
 no declaration of `T` in the real `A.hs`, so the knot tying will fail.

 It's not entirely clear to me how to deal with this problem.  The obvious
 thing to do is to fault in the `TyThing` from the ModDetails of the hs-
 boot file (great care must be taken because we don't actually want to load
 the hs-boot file!) We'll then fail in due course when we check if we
 actually implement everything the hs-boot file needs.

 But this could complicate things:

 1. This "robustness" could mask another, much more difficult to diagnose
 bug when there was an actual knot-tying failure. Then, we will silently
 fail to tie the knot, and then if something bad happens it is a lot less
 obvious what went wrong. However! I think there is an ASSERT we can add in
 this case: when we add things to the type environment (and update the knot
 tying variable), we can check if we have faulted in the relevant entity
 from the hs-boot file. If we have, then we know there is knot-tying
 failure and we should fail.

 2. Having two sets of `TyThing`s for the same `Name` could lead to hard to
 diagnose errors; e.g., you are comparing `S` for equality with `S`, but
 they return not equal because one of these is a type synonym tycon and the
 other is an abstract tycon. There might be some adjustments to the debug
 printing mechanism to make such situations more obvious.

 Here is another way to fix the bug: check if all the types declared in the
 hs-boot file are actually defined before doing any typechecking proper.
 Interestingly, this is a possible solution for #12034: the implication is
 that all types mentioned in the hs-boot file must be defined PRIOR to the
 first splice. If we look at #1012, this would not be a burden for users
 that use TH and hs-boot. Also, it nicely fits with a solution for #12042,
 since we need to check for type synonym loops at some point BEFORE
 typechecking, and this is the obvious place to do so.

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