[GHC] #15147: Type checker plugin receives Wanteds that are not completely unflattened

[GHC]

#15147: Type checker plugin receives Wanteds that are not completely unflattened
-------------------------------------+-------------------------------------
        Reporter:  nfrisby           |                Owner:  (none)
            Type:  bug               |               Status:  new
        Priority:  normal            |            Milestone:  8.8.1
       Component:  Compiler (Type    |              Version:  8.4.1
  checker)                           |             Keywords:
      Resolution:                    |  TypeCheckerPlugins
Operating System:  Unknown/Multiple  |         Architecture:
                                     |  Unknown/Multiple
 Type of failure:  None/Unknown      |            Test Case:
      Blocked By:                    |             Blocking:
 Related Tickets:                    |  Differential Rev(s):
       Wiki Page:                    |
-------------------------------------+-------------------------------------

Comment (by nfrisby):

 I now believe my work-in-progress plugin could be simpler, if a few parts
 of the plugin API changed. One of those is if the fsks and fmvs were both
 left in place in both Givens and in Wanteds; no extra unflattening before
 invoking plugins.

 I have a related request: directly provide the list of all in-scope
 variables bound by the enclosing and current implications. This would
 include the flattening variables with their definitions (preferably in a
 topological order), instead of having to partition their defining
 constraints from the passed in {{{Ct}}}s. In particular, it's awkward that
 some fsks are defined as an alias of another by a {{{CTyEqCan}}}, not by a
 {{{CFunEq}}} -- there is no {{{CFunEq}}} for such fsks, just the
 {{{CTyEqCan}}}. I'm not sure when this happens, but I'm definitely seeing
 it in GHC 8.6.2.

 That list would also include skolem binders pretty easily -- the fsk, fmv,
 and skolem lists are already in data structures (implication, inert cans).
 Ideally the list would also include unification variables, but I don't
 think their list is maintained anywhere currently, so I imagine their
 might be a good reason for that.

 But. If I had the unflattened constraints as-is from GHC, and a list of
 all in-scope type variables (incl covars?), my life as plugin author would
 be much easier. That would let me replace my type and coercion traversing
 code with just calls to the {{{subst}}} functions. My final ingredient for
 this wishlist would be for the {{{subst*}}} functions to indicate if they
 ever applied the passed-in substitution: I need to know if a substitution
 actually applied to a constraint. I could ask for free vars before
 substing, but that incurs a redundant traversal.

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