[GHC] #13601: GHC errors but hangs

[GHC]

#13601: GHC errors but hangs
-------------------------------------+-------------------------------------
        Reporter:  Iceland_jack      |                Owner:  (none)
            Type:  bug               |               Status:  new
        Priority:  normal            |            Milestone:
       Component:  Compiler          |              Version:  8.0.1
      Resolution:                    |             Keywords:  TypeInType,
                                     |  LevityPolymorphism
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 goldfire):

 The `uo_thing` field was introduced in order to keep error messages
 reasonably stable during the `TypeInType` merge. Pre-`TypeInType`, kind
 errors reported what type had the kind that was involved in the error, and
 I wanted to keep this functionality post-`TypeInType`. That's the only
 reason the field exists. It was (and is) my hope to use `uo_thing` also
 for term-level error messages, as I think we can improve these through its
 use.

 One of the grim aspects of `uo_thing` is that `unifyType`'s type starts
 with `Outputable a => Maybe a -> ...` in order to use (possibly) something
 as the thing in the `uo_thing` field. But passing `Nothing` to `unifyType`
 causes ambiguity errors, because we can't know what `a` should be. So I
 have `noThing :: Maybe (HsExpr Name); noThing = Nothing` to resolve the
 ambiguity. I've been meaning to clean this up.

 Another missed opportunity after `TypeInType` is to use `TcTyCon` more
 fully. Type-checking can produce `TcTyCon`s instead of `TyCon`s, with the
 latter rewriting to the former only during the final zonk. This would mean
 that the type-checking knot needs to cover only zonking, instead of type-
 checking. That would surely fix this bug.

 In more direct response to comment:4, I'm dubious. If `solveEqualities`
 fails, then there is something ill-kinded lurking about, and I'm worried
 that some `failIfErrsM` and such won't fire, causing chaos. It may be
 possible to rein in the chaos, but I don't think it will be an easy win.

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