#9580: Possible excessive leniency in interaction between coerce and data families? -------------------------------------+------------------------------------- Reporter: dmcclean | Owner: simonpj Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 7.8.3 (Type checker) | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones <simonpj@…>): In [changeset:"0aaf812ed0a4a4be9528b2e2f6b72bee7cd8002d/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="0aaf812ed0a4a4be9528b2e2f6b72bee7cd8002d" Clean up Coercible handling, and interaction of data families with newtypes This patch fixes Trac #9580, in which the Coercible machinery succeeded even though the relevant data constructor was not in scope. As usual I got dragged into a raft of refactoring changes, all for the better. * Delete TcEvidence.coercionToTcCoercion (now unused) * Move instNewTyConTF_maybe, instNewTyCon_maybe to FamInst, and rename them to tcInstNewTyConTF_maybe, tcInstNewTyCon (They both return TcCoercions.) * tcInstNewTyConTF_maybe also gets more convenient type, which improves TcInteract.getCoercibleInst * Define FamInst.tcLookupDataFamInst, and use it in TcDeriv, (as well as in tcInstNewTyConTF_maybe) * Improve error report for Coercible errors, when data familes are involved Another use of tcLookupDataFamInst * In TcExpr.tcTagToEnum, use tcLookupDataFamInst to replace local hacky code * Fix Coercion.instNewTyCon_maybe and Type.newTyConInstRhs to deal with eta-reduced newtypes, using (new) Type.unwrapNewTyConEtad_maybe and (new) Type.applyTysX Some small refactoring of TcSMonad.matchFam. }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9580#comment:4> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler