[GHC] #14777: panic when using a function defined in terms of `error`

[GHC]

#14777: panic when using a function defined in terms of `error`
-------------------------------------+-------------------------------------
        Reporter:  zilinc            |                Owner:  simonpj
            Type:  bug               |               Status:  new
        Priority:  normal            |            Milestone:  8.6.1
       Component:  Compiler          |              Version:  8.2.2
      Resolution:                    |             Keywords:
Operating System:  Linux             |         Architecture:
 Type of failure:  Compile-time      |  Unknown/Multiple
  crash or panic                     |            Test Case:
      Blocked By:                    |             Blocking:
 Related Tickets:                    |  Differential Rev(s):
       Wiki Page:                    |
-------------------------------------+-------------------------------------

Comment (by Simon Peyton Jones <simonpj@…>):

 In [changeset:"3446cee05e08d78033e141fa46d4de6929542cbb/ghc"
 3446cee0/ghc]:
 {{{
 #!CommitTicketReference repository="ghc"
 revision="3446cee05e08d78033e141fa46d4de6929542cbb"
 Fix two obscure bugs in rule matching

 This patch fixes Trac #14777, a compiler crash.

 There were actually two bugs.

 1. In Rules.matchN, I was (consciously) not rename the template binders
    of the rule. Sadly, in rare cases an accidental coincidence of
    uniques could mean that a term variable was mapped to a type
    variable, utterly bogusly.  See "Historical note" in
    Note [Cloning the template binders] in Rules.

    This was hard to find, but easy to fix.

 2. The fix to (1) showed up a bug in Unify.hs.  The test in
    Unify.tvBindFlag was previously using the domain of the RnEnv2
    to detect locally-bound variables (e.g. when unifying under
    a forall).  That's fine when teh RnEnv2 starts empty, as it
    does in most entry points.  But the tcMatchTyKisX entry point,
    used from the rule matcher, passes in a non-empty RnEnv2 (by
    design).  Now the domain of the RnEnv doesn't idenfity those
    locally-bound variables any more :-(.

    Solution: extend UmEnv with a new field um_skols, to capture
    the skolems directly.  Simple, easy, works.
 }}}

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