#15370: Typed hole panic on GHC 8.6 (tcTyVarDetails) -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Tritlo Type: bug | Status: new Priority: high | Milestone: 8.6.1 Component: Compiler (Type | Version: 8.4.3 checker) | Keywords: TypeInType, Resolution: | TypedHoles Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): I have a hypothesis about the assertion failure in comment:4 I see in `TcHoleErrors.tcCheckHoleFit` {{{ ; let w_rel_cts = addSimples wanted relevantCts ... ; let w_givens = foldr setWC w_rel_cts outermost_first ... ; rem <- runTcSDeriveds $ simpl_top w_givens }}} So the same `relevantCts` are used in multiple runs of `runTcSDerived`. You are careful to freshen the `ic_binds` of the implicatations, but if `relevantCts` contains any equalities they will have `HoleDest`, a coercion hole that is filled in directly. You really need to clone those holes too. Use `TcMType.cloneWanted` as in `cloneWC`. As it happens, this `cloneWanted` is overkill, and I'm improving it in an upcoming patch, but for now I think it'll do what you need. Does that make sense? Best to verify that this is indeed what is happening. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/15370#comment:10 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler