[GHC] #11254: GHC panic

GHC ghc-devs at haskell.org
Fri Dec 18 18:50:32 UTC 2015


#11254: GHC panic
---------------------------------+----------------------------------------
        Reporter:  Iceland_jack  |                Owner:  goldfire
            Type:  bug           |               Status:  new
        Priority:  normal        |            Milestone:
       Component:  Compiler      |              Version:  7.11
      Resolution:                |             Keywords:
Operating System:  Linux         |         Architecture:  Unknown/Multiple
 Type of failure:  None/Unknown  |            Test Case:
      Blocked By:                |             Blocking:
 Related Tickets:                |  Differential Rev(s):
       Wiki Page:                |
---------------------------------+----------------------------------------

Comment (by goldfire):

 From TcErrors:

 {{{
 Note [Deferred errors for coercion holes]
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 Suppose we need to defer a type error where the destination for the
 evidence
 is a coercion hole. We can't just put the error in the hole, because we
 can't
 make an erroneous coercion. (Remember that coercions are erased for
 runtime.)
 Instead, we invent a new EvVar, bind it to an error and then make a
 coercion
 from that EvVar, filling the hole with that coercion. Because coercions'
 types are unlifted, the error is guaranteed to be hit before we get to the
 coercion.
 }}}

 But that's admittedly not the whole story. This also matters, from
 `TcUnify.buildImplication`:

 {{{
       -- But with the solver producing unlifted equalities, we need
       -- to have an EvBindsVar for them when they might be deferred to
       -- runtime. Otherwise, they end up as top-level unlifted bindings,
       -- which are verboten. See also Note [Deferred errors for coercion
 holes]
       -- in TcErrors.
 }}}

 The comment describes a check to make sure that we always build an
 implication when `-fdefer-type-errors` is on (and we're at top-level). I
 noticed an unexpected `pushTcLevelM` at !TcInstDecls:811 that may throw
 this check off.

 Do you have a recommendation for how to improve the documentation?

 I'll look into this.

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


More information about the ghc-tickets mailing list