#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 adamgundry): Okay, let me try to summarise: 1. When a type-checker plugin is in use, we zonk the constraints before calling the plugin. Thus plugins don't need to worry about doing their own zonking. 2. Zonking a `CDictCan` constraint (or indeed anything other than a `CHoleCan`) turns it into a `CNonCanonical`. Presumably this is because zonking may not preserve the invariants of all the canonical constraints, so they might need to be re-canonicalized if they are looked at again later. 3. The `expandSuperClasses` step, which runs after the simple wanted and plugin loop, looks for `CDictCan`s. If a plugin is in use, 1 and 2 mean that it doesn't find any, and hence fails to expand superclasses. This leads to the solving failure reported in this ticket. If we can make `zonkCt` preserve `CDictCan` rather than turning it into `CNonCanonical`, then `expandSuperClasses` should just work even in the presence of plugins. However, it isn't completely obvious to me whether the invariants of `CDictCan` (e.g. the fact that `cc_tyargs` is "function- free") will still hold after zonking. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/11525#comment:6 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler