[GHC] #14628: Panic (No skolem Info) in GHCi

[GHC]

#14628: Panic (No skolem Info) in GHCi
-------------------------------------+-------------------------------------
        Reporter:  AndreasK          |                Owner:  (none)
            Type:  bug               |               Status:  new
        Priority:  normal            |            Milestone:
       Component:  GHCi              |              Version:  8.2.2
      Resolution:                    |             Keywords:  debugger
Operating System:  Unknown/Multiple  |         Architecture:
 Type of failure:  Compile-time      |  Unknown/Multiple
  crash or panic                     |            Test Case:
      Blocked By:                    |             Blocking:
 Related Tickets:  #13393            |  Differential Rev(s):
       Wiki Page:                    |
-------------------------------------+-------------------------------------

Comment (by simonpj):

 I think it's unrelated to the fix for #13393.

 As you point out, this is debugger-land, and we have these `RuntimeUnk`
 skolems, which stand for as-yet-unknown types in the debugger. In this
 case `_result` has type
 {{{
 _result :: StateT Int m_I4K0[rt] ()
 }}}
 but the debugger can't figure out (by looking at the heap) what this
 `m_I4K0` type is.  So when typechecking an expression involving `_result`
 we should complain if this `m` gets unified with anything.  And it is when
 you try to evalute
 {{{
 snd $ runStateT _result 0
 }}}
 We get a wanted constraint
 {{{
   [WD] hole{a4SP} :: (m_I4K0[rt] :: (* -> *))  ~# ((,) a_a4SI[tau:1] :: (*
 -> *))
 }}}
 The trouble is that, in reporting the error, `TcErrors.getSkolemInfo` of
 course cannot find an enclosing implication constraint binding that `m`.

 What we should do instead is:

 * Make `getSkolemInfo` return a `SkolemInfo` rether than an `Implic`
 * If `getSkolemInfo` gets a `RuntimeUnk`, just return a new data
 constructor in `SkolemInfo`, perhpas `RuntimeUnkSkol`.
 * In `TcErrors.pprSkols` print something sensible for a `RuntimeUnkSkol`

 It'd be most helpful to look at the top-level type envt, and display some
 of the in-scope Ids that have that variale free in their types.  The
 `relevantBindings` function might be good for finding such bindings.

 Any volunteers?

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