#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