#4809: MonoLocalBinds and type classes cause infinite loop ---------------------------------+------------------------------------------ Reporter: JeremyShaw | Owner: Type: bug | Status: merge Priority: normal | Milestone: Component: Compiler | Version: 7.0.1 Keywords: | Testcase: typecheck/should_run/T4809 Blockedby: | Difficulty: Os: Unknown/Multiple | Blocking: Architecture: Unknown/Multiple | Failure: Incorrect result at runtime ---------------------------------+------------------------------------------ Changes (by simonpj):
* status: new => merge * testcase: => typecheck/should_run/T4809 Comment: I believe we have now, finally, fixed this. {{{ Mon Dec 13 09:15:11 PST 2010 simo...@microsoft.com * Fix recursive superclasses (again). Fixes Trac #4809. This patch finally deals with the super-delicate question of superclases in possibly-recursive dictionaries. The key idea is the DFun Superclass Invariant (see TcInstDcls): In the body of a DFun, every superclass argument to the returned dictionary is either * one of the arguments of the DFun, or * constant, bound at top level To establish the invariant, we add new "silent" superclass argument(s) to each dfun, so that the dfun does not do superclass selection internally. There's a bit of hoo-ha to make sure that we don't print those silent arguments in error messages; a knock on effect was a change in interface-file format. A second change is that instead of the complex and fragile "self dictionary binding" in TcInstDcls and TcClassDcl, using the same mechanism for existential pattern bindings. See Note [Subtle interaction of recursion and overlap] in TcInstDcls and Note [Binding when looking up instances] in InstEnv. Main notes are here: * Note [Silent Superclass Arguments] in TcInstDcls, including the DFun Superclass Invariant Main code changes are: * The code for MkId.mkDictFunId and mkDictFunTy * DFunUnfoldings get a little more complicated; their arguments are a new type DFunArg (in CoreSyn) * No "self" argument in tcInstanceMethod * No special tcSimplifySuperClasss * No "dependents" argument to EvDFunApp IMPORTANT It turns out that it's quite tricky to generate the right DFunUnfolding for a specialised dfun, when you use SPECIALISE INSTANCE. For now I've just commented it out (in DsBinds) but that'll lose some optimisation, and I need to get back to this. M ./compiler/basicTypes/Id.lhs -3 +8 M ./compiler/basicTypes/IdInfo.lhs -7 +14 M ./compiler/basicTypes/MkId.lhs -12 +24 M ./compiler/coreSyn/CoreFVs.lhs -1 +1 M ./compiler/coreSyn/CoreSubst.lhs -1 +3 M ./compiler/coreSyn/CoreSyn.lhs -9 +23 M ./compiler/coreSyn/CoreTidy.lhs -1 +1 M ./compiler/coreSyn/CoreUnfold.lhs -4 +6 M ./compiler/coreSyn/CoreUtils.lhs -1 +1 M ./compiler/coreSyn/PprCore.lhs -2 +6 M ./compiler/deSugar/DsBinds.lhs -29 +15 M ./compiler/hsSyn/HsBinds.lhs -4 +1 M ./compiler/hsSyn/HsExpr.lhs-boot +4 M ./compiler/hsSyn/HsPat.lhs-boot +1 M ./compiler/iface/BinIface.hs -2 +13 M ./compiler/iface/IfaceSyn.lhs -8 +7 M ./compiler/iface/MkIface.lhs -2 +2 M ./compiler/iface/TcIface.lhs -3 +6 M ./compiler/main/TidyPgm.lhs -1 +1 M ./compiler/simplCore/Simplify.lhs -1 +1 M ./compiler/typecheck/Inst.lhs -3 +11 M ./compiler/typecheck/TcClassDcl.lhs -17 +7 M ./compiler/typecheck/TcDeriv.lhs -21 +22 M ./compiler/typecheck/TcEnv.lhs -2 +2 M ./compiler/typecheck/TcErrors.lhs -9 +10 M ./compiler/typecheck/TcHsSyn.lhs -2 +2 M ./compiler/typecheck/TcHsType.lhs -28 +30 M ./compiler/typecheck/TcInstDcls.lhs -143 +178 M ./compiler/typecheck/TcInteract.lhs -3 +2 M ./compiler/typecheck/TcMType.lhs -49 +34 M ./compiler/typecheck/TcSMonad.lhs -5 +3 M ./compiler/typecheck/TcSimplify.lhs -115 +5 M ./compiler/typecheck/TcType.lhs -5 +8 M ./compiler/typecheck/TcUnify.lhs -7 +5 M ./compiler/types/InstEnv.lhs -8 +18 M ./compiler/vectorise/Vectorise/Type/PADict.hs -1 +2 }}} This needs to merge to stable. Simon -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/4809#comment:6> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler _______________________________________________ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs