#9424: ghc-api/T8628 fails assert on debugged ghc -------------------------------------+------------------------------------- Reporter: slyfox | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones <simonpj@…>): In [changeset:"67a0cab6b501e2d6280b51655af66ad448b3deef/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="67a0cab6b501e2d6280b51655af66ad448b3deef" Fix GHCi/GHC-API tidying and modules (Trac #9424, #9426) There were two related bugs here Trac #9426 We must increment the ic_mod_index field of the InteractiveContext if we have new instances, because we maek DFunIds that should be distinct from previous ones. Previously we were only incrementing when defining new user-visible Ids. The main change is in HscTypes.extendInteractiveContext, which now alwyas bumps the ic_mod_index. I also added a specialised extendInteractiveContextWithIds for the case where we are *only* adding new user-visible Ids. Trac #9424 In HscMain.hscDeclsWithLocations we were failing to use the *tidied* ClsInsts; but the un-tidied ones are LocalIds which causes a later ASSERT error. On the way I realised that, to behave consistently, the tcg_insts and tcg_fam_insts field of TcGblEnv should really only contain instances from the current GHCi command, not all the ones to date. That in turn meant I had to move the code for deleting replacement instances from addLocalInst, addLocalFamInst to HscTypes.extendInteractiveContext }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9424#comment:1> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler