#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 simonpj):
also the NB comment right after the call to isReflexiveCo.
To be explicit, you mean {{{ mkCastTy :: Type -> Coercion -> Type mkCastTy ty co | isReflexiveCo co = ty -- (EQ2) from the Note -- NB: Do the slow check here. This is important to keep the splitXXX -- functions working properly. Otherwise, we may end up with something -- like (((->) |> something_reflexive_but_not_obviously_so) biz baz) -- fails under splitFunTy_maybe. This happened with the cheaper check -- in test dependent/should_compile/dynamic-paper. }}}
Suppose we have tyco :: Type ~ Coercion
It's worth noting that the type checker will produce an error message for any such coercion. It's like `Int ~ Bool`. I feel somewhat relaxed about the impact on Core of not upholding an equality that will be rejected by the typechecker anyway. (Long term I think we probably want to make Type and Coercion distinct everywhere.)
mkCastTy discards reflexive coercions that aren't Type-vs-Coercion, and coreView discards the rest
Hm. You mean something like {{{ tcView (ty |> co) | ty1 == coercionKind, ty2 == typeKind = Just ty | ty1 = typeKind, ty2 == coercionKind = Just ty where (ty1,ty2) = coercionKind co }}} I suppose that'd be possible. But I agree it's smelly. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/15918#comment:9 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler