#11525: Using a dummy typechecker plugin causes an ambiguity check error -------------------------------------+------------------------------------- Reporter: jme | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler (Type | Version: 8.0.1-rc1 checker) | Keywords: Resolution: | UndecidableSuperClasses, plugin Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Oh, (3) is terrible! It's find just to elaborate `zonkCt`. Constraints are always re-flattened etc even if they come in as `CDictCan`. Only canonical constraints that are actually ''in the inert set'' carry all the guarantees. That point should be more carefully documented, I agree. It's a bit more code to do this (which is, I think, why `zonkCt` currently always returns a `CNonCanonical`), so please include a Note to explain. Also * `CTyEqCan`: flattening the LHS might not give a type variable; if not, return a `CNonCanonical`. * `CFunEqCan`: you could do the same for the `cc_fsk` field, but I don't think `zonkCt` should ever encounter a `CFunEqCan`, because the latter are removed by `TcFlatten.unflatten`. So you could just crash. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/11525#comment:7 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler