#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 (Type | Version: 8.1 checker) | Resolution: | Keywords: hs-boot Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by ezyang: @@ -17,0 +17,1 @@ + x = undefined New description: 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 x = undefined }}} 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#comment:1 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler