[GHC] #11331: panic! TEST=tc198: lookupVers2 GHC.Stack.Types CallStack

[GHC]

#11331: panic! TEST=tc198: lookupVers2 GHC.Stack.Types CallStack
-------------------------------------+-------------------------------------
        Reporter:  thomie            |                Owner:  gridaphobe
            Type:  bug               |               Status:  new
        Priority:  highest           |            Milestone:  8.0.1
       Component:  Compiler          |              Version:  7.11
      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 simonpj):

 Look at `Note [Loading instances for wired-in things]` in `LoadIface`.

 You should call `checkWiredInTyCon` when (but only when) you are using
 `CallStack` but not ''mentioning'' it.  A classic example is when you
 write
 {{{
 f :: [a] -> [a]
 }}}
 The explicit list syntax `[a]` uses `listTyCon` but does not mention it
 explicitly. Ditto tuples.  Hence the calls to `checkWiredInTyCon` in
 `TcHsType`.

 Ah!  I see what is happening.
  * `tc198` uses `undefined`, which is wired-in.
  * But the type of `undefined` mentions `CallStack`.
  * In `tcImportDecl_maybe`, we check for wired-in things, and call
 `loadWiredInHomeInterface` -- but only if `needWiredInHomeInterface` is
 True.
  * `needWiredInHomeInterace` is False of Ids; and even if it were True,
 we'd load `undefined`'s home interface not `CallStack`'s.

 The reason for the `loadWiredInHomeInterface` stuff is really to get
 `instance` declarations.  And I suppose that if we have a wired-in Id
 whose type is `Bool -> M.T`, then we perhaps ought to check that `M.T`'s
 home interface is loaded in case there are any instances for it which we
 might need.

 So one solution is to adapt the wired-in-Id case of `tcImportDecl_maybe`
 to call `checkWiredInTyCon` on any `TyCon`s in the Id's type.

 But in fact the reason we need the home interface is ''not'' because of
 instances but to get its fingerprint. And it does seem bizarre to me that
 the fingerprint of a wired-in thing appears in the interface file if thing
 itself does not.  Can't we give all wired-in things a fingerprint of zero?
 After all, they are wired-in.  If we change them we change the compiler,
 and there are many cases in which changing the compiler requires a clean
 rebuild.  In this case the worst that could happen would be some missing
 recompilation, and that is also an issue when, for example, we change
 interface file format.

 So I say that for wired-in things
  * make `MkIface.mkHashFun` return zero for wired-in names
  * filter out wired-in names when constructing fingerprints

 That would solve this ticket.  Technically there is still a potential
 problem with missing instances (see above) but in practice it doesn't
 occur, and closing that theoretical hole would take more code and slow
 down every compilation.

 Any other observations/thoughts?

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