[GHC] #11525: Using a dummy typechecker plugin causes an ambiguity check error

[GHC]

#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