[GHC] #15846: Re-examine mkResidualConstraints

[GHC]

#15846: Re-examine mkResidualConstraints
-------------------------------------+-------------------------------------
           Reporter:  goldfire       |             Owner:  (none)
               Type:  bug            |            Status:  new
           Priority:  normal         |         Milestone:
          Component:  Compiler       |           Version:  8.6.1
           Keywords:                 |  Operating System:  Unknown/Multiple
       Architecture:                 |   Type of failure:  None/Unknown
  Unknown/Multiple                   |
          Test Case:                 |        Blocked By:
           Blocking:                 |   Related Tickets:
Differential Rev(s):                 |         Wiki Page:
-------------------------------------+-------------------------------------
 Simon and I spent some time debating `TcSimplify.mkResidualConstraints`.
 Here is what we learned:

 * The current code handles covars at the top level only. At one point, we
 were worried about covars in nested implications. But I conjecture this
 can't happen, because these would necessarily be instances of skolem-
 escape, prevented elsewhere. (Why skolem-escape? Because the covar would
 mention local skolems, and yet appears in the type of the variable(s)
 we're trying to infer.)

 * We think that any covars that come through `mkResidualConstraints` will
 ''never'' be solved. That's because there can't be given equality from an
 outer context -- if there were, we'd be in the "let should not be
 generalized" case and wouldn't be in `simplifyInfer`.

 *  The `promoteTyVarSet` call in `mkResidualConstraints` appears to be
 entirely redundant, because anything that gets caught there should also
 have been caught in `decideMonoTyVars`.

 * So the only time that we should do work in `mkResidualConstraints` is
 when we have deferred type errors. Perhaps with that insight, it can be
 simplified.

 This ticket is to track our understanding of this function, settle on a
 way to improve it, and then execute that change. At the minimum, we should
 figure out whether that `promoteTyVarSet` is necessary.

-- 
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15846>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler