[GHC] #15141: decideKindGeneralisationPlan is too complicated

[GHC]

#15141: decideKindGeneralisationPlan is too complicated
-------------------------------------+-------------------------------------
        Reporter:  simonpj           |                Owner:  (none)
            Type:  bug               |               Status:  patch
        Priority:  normal            |            Milestone:  8.8.1
       Component:  Compiler          |              Version:  8.2.2
      Resolution:                    |             Keywords:
Operating System:  Unknown/Multiple  |         Architecture:
                                     |  Unknown/Multiple
 Type of failure:  None/Unknown      |            Test Case:
      Blocked By:                    |             Blocking:
 Related Tickets:                    |  Differential Rev(s):  Phab:D4971
       Wiki Page:                    |
-------------------------------------+-------------------------------------

Comment (by Richard Eisenberg <rae@…>):

 In [changeset:"c955a514f033a12f6d0ab0fbacec3e18a5757ab5/ghc" c955a51/ghc]:
 {{{
 #!CommitTicketReference repository="ghc"
 revision="c955a514f033a12f6d0ab0fbacec3e18a5757ab5"
 Remove decideKindGeneralisationPlan

 TypeInType came with a new function: decideKindGeneralisationPlan.
 This type-level counterpart to the term-level decideGeneralisationPlan
 chose whether or not a kind should be generalized. The thinking was
 that if `let` should not be generalized, then kinds shouldn't either
 (under the same circumstances around -XMonoLocalBinds).

 However, this is too conservative -- the situation described in the
 motivation for "let should be be generalized" does not occur in types.

 This commit thus removes decideKindGeneralisationPlan, always
 generalizing.

 One consequence is that tc_hs_sig_type_and_gen no longer calls
 solveEqualities, which reports all unsolved constraints, instead
 relying on the solveLocalEqualities in tcImplicitTKBndrs. An effect
 of this is that reporing kind errors gets delayed more frequently.
 This seems to be a net benefit in error reporting; often, alongside
 a kind error, the type error is now reported (and users might find
 type errors easier to understand).

 Some of these errors ended up at the top level, where it was
 discovered that the GlobalRdrEnv containing the definitions in the
 local module was not in the TcGblEnv, and thus errors were reported
 with qualified names unnecessarily. This commit rejiggers some of
 the logic around captureTopConstraints accordingly.

 One error message (typecheck/should_fail/T1633)
 is a regression, mentioning the name of a default method. However,
 that problem is already reported as #10087, its solution is far from
 clear, and so I'm not addressing it here.

 This commit fixes #15141. As it's an internal refactor, there is
 no concrete test case for it.

 Along the way, we no longer need the hsib_closed field of
 HsImplicitBndrs (it was used only in decideKindGeneralisationPlan)
 and so it's been removed, simplifying the datatype structure.

 Along the way, I removed code in the validity checker that looks
 at coercions. This isn't related to this patch, really (though
 it was, at one point), but it's an improvement, so I kept it.

 This updates the haddock submodule.
 }}}

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