[GHC] #14584: Core Lint error

GHC ghc-devs at haskell.org
Tue Dec 19 12:00:21 UTC 2017


#14584: Core Lint error
-------------------------------------+-------------------------------------
        Reporter:  Iceland_jack      |                Owner:  (none)
            Type:  bug               |               Status:  new
        Priority:  normal            |            Milestone:
       Component:  Compiler          |              Version:  8.2.1
      Resolution:                    |             Keywords:  TypeInType,
                                     |  DeferredTypeErrors
Operating System:  Unknown/Multiple  |         Architecture:
                                     |  Unknown/Multiple
 Type of failure:  None/Unknown      |            Test Case:
      Blocked By:                    |             Blocking:
 Related Tickets:                    |  Differential Rev(s):
       Wiki Page:                    |
-------------------------------------+-------------------------------------
Changes (by simonpj):

 * cc: goldfire (added)


Comment:

 Yurgh.   I don't yet understand the details, but what is happening is
 something like this.  We have an implication constraint
 {{{
 forall x[2].
    [W] co1: alpaha[1] ~ ty |> co2
    [W] co2: k1 ~ *
 }}}
 Here `co2` is an ultimately-unsolved kind coercion.  We float `co1` out of
 the implication and unify with `alpha`.  Then in `TcErrors` we make
 evidence for `co2` using a call to `error`, bound in the `EvBinds` for the
 implication.

 But alas the scope of the binding for `co2` is just the term enclosed by
 the implication constraint.  But the use of `co2` has escaped, in the type
 `alpha`.

 Yikes.  This only shows up with deferred type errors, because normally we
 don't make term-level bindings for coercions; instead we just side-effect
 them right into the coercions they are used in, which just happens to work
 even in the "escaping" case.  But with deferred type errors we need to
 force a term-level error, and to do so in as narrow a scope as possible.

 I'd like a smaller test case to show this up.

 I really do not know how to solve this.  It's all because of those pesky
 casts inside types!  Richard, your advice would be valuable here.

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


More information about the ghc-tickets mailing list