#14175: Panic repSplitTyConApp_maybe -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.2.2 Component: Compiler (Type | Version: 8.2.1 checker) | Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: #13910 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones <simonpj@…>): In [changeset:"8bf865d3db69c6f4a09f3e5e3880c087c0a7c7f0/ghc" 8bf865d3/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="8bf865d3db69c6f4a09f3e5e3880c087c0a7c7f0" Tidying could cause ill-kinded types I found (Trac #14175) that the tidying we do when reporting type error messages could cause a well-kinded type to become ill-kinded. Reason: we initialised the tidy-env with a completely un-zonked TidyEnv accumulated in the TcLclEnv as we come across lexical type-varialbe bindings. Solution: zonk them. But I ended up refactoring a bit: * Get rid of tcl_tidy :: TidyEnv altogether * Instead use tcl_bndrs :: TcBinderStack This used to contain only Ids, but now I've added those lexically scoped TyVars too. * Change names: TcIdBinderStack -> TcBinderStack TcIdBinder -> TcBinder extendTcIdBndrs -> extendTcBinderStack * Now tcInitTidyEnv can grab those TyVars from the tcl_bndrs, zonk, and tidy them. The only annoyance is that I had to add TcEnv.hs-boot, to break the recursion between the zonking code and the TrRnMonad functions like addErrTc that call tcInitTidyEnv. Tiresome, but in fact that file existed already. }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14175#comment:7> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler