[GHC] #15918: GHC panic from QuantifiedConstraints(?)

[GHC]

#15918: GHC panic from QuantifiedConstraints(?)
-------------------------------------+-------------------------------------
        Reporter:  Iceland_jack      |                Owner:  (none)
            Type:  bug               |               Status:  new
        Priority:  normal            |            Milestone:
       Component:  Compiler          |              Version:  8.6.2
      Resolution:                    |             Keywords:
                                     |  QuantifiedConstraints
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):

 I do mean that note, and also the NB comment right after the call to
 `isReflexiveCo`.

 You're right about the `mkNakedCastTy`. There could be a latent bug there,
 because `tcSplitTyConApp` won't work as it should if a cast makes a
 `TyConApp` look like something else.

 >  How bad would it be if `mkCastTy` did not remove a cast between `Type`
 and `Coercion`?

 It's potentially bad. Suppose we have `tyco :: Type ~ Coercion`. Then
 `Bool |> tyco` is `eqType` to `Bool`, but `splitTyConApp` behaves
 differently on them.

 Here's another approach: what if `coreView` dispenses with reflexive
 coercions, not `mkCastTy`? We're already careful to use `coreView`
 liberally. Implemented correctly, this should satisfy the definitional
 equality concerns. The problem will be performance: it's potentially
 expensive to check coercion types and compute equality, and `coreView` is
 called a lot. (Specifically, it's a shame to build a cast only to have to
 remove it lots of times.) But maybe we could take a hybrid approach:
 `mkCastTy` discards reflexive coercions that aren't `Type`-vs-`Coercion`,
 and `coreView` discards the rest. (`tcView` wouldn't, of course!) That
 would work, I think, but I'm not in love with the approach.

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