[GHC] #14331: Overzealous free-floating kind check causes deriving clause to be rejected

[GHC]

#14331: Overzealous free-floating kind check causes deriving clause to be rejected
-------------------------------------+-------------------------------------
        Reporter:  RyanGlScott       |                Owner:  (none)
            Type:  bug               |               Status:  new
        Priority:  normal            |            Milestone:  8.4.1
       Component:  Compiler (Type    |              Version:  8.2.1
  checker)                           |
      Resolution:                    |             Keywords:  deriving
Operating System:  Unknown/Multiple  |         Architecture:
                                     |  Unknown/Multiple
 Type of failure:  GHC rejects       |            Test Case:
  valid program                      |  deriving/should_compile/T14331
      Blocked By:                    |             Blocking:
 Related Tickets:                    |  Differential Rev(s):
       Wiki Page:                    |
-------------------------------------+-------------------------------------

Comment (by goldfire):

 I'm taking a look at your work, but it would be much more ergonomic to
 review this in Phab.

 Rough comments:
  - Why the `newMetaTyVars` at the top? That doesn't look right to me.

  - You're trying to swap the `tcUnifyTy` with a `unifyType`. Good. But the
 `tcUnifyTy` is still there. Is this intentional or an aspect of the fact
 that this is w.i.p.?

  - Before you call `unifyType`, you need to have metavariables that
 `unifyType` will unify. According to comment:31, these variables should be
 as specified in step (h) of the algorithm. So perhaps you do need
 `newMetaTyVars`, but not over all the tvs, just a subset of them.

 - The second half of step (i) of the algorithm (skolemizing unbound
 metavariables) might nicely be accomplished by `quantifyTyVars`. It's a
 bit unclear to me without thinking more about this whether this function
 does too much, but its helper function `zonkQuantifiedTyVar` is definitely
 what you need to do.

 I hope this gets you going again...

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