#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