[GHC] #14932: DeriveAnyClass produces unjustifiably untouchable unification variables

[GHC]

#14932: DeriveAnyClass produces unjustifiably untouchable unification variables
-------------------------------------+-------------------------------------
        Reporter:  RyanGlScott       |                Owner:  (none)
            Type:  bug               |               Status:  patch
        Priority:  normal            |            Milestone:
       Component:  Compiler (Type    |              Version:  8.4.1
  checker)                           |
      Resolution:                    |             Keywords:  deriving
Operating System:  Unknown/Multiple  |         Architecture:
 Type of failure:  GHC rejects       |  Unknown/Multiple
  valid program                      |            Test Case:
      Blocked By:                    |             Blocking:
 Related Tickets:  #13272, #14933    |  Differential Rev(s):  Phab:D4507
       Wiki Page:                    |
-------------------------------------+-------------------------------------

Comment (by Ben Gamari <ben@…>):

 In [changeset:"9893042604cda5260cb0f7b674ed5c34b419e403/ghc" 9893042/ghc]:
 {{{
 #!CommitTicketReference repository="ghc"
 revision="9893042604cda5260cb0f7b674ed5c34b419e403"
 Fix two pernicious bugs in DeriveAnyClass

 The way GHC was handling `DeriveAnyClass` was subtly wrong
 in two notable ways:

 * In `inferConstraintsDAC`, we were //always// bumping the `TcLevel`
   of newly created unification variables, under the assumption that
   we would always place those unification variables inside an
   implication constraint. But #14932 showed precisely the scenario
   where we had `DeriveAnyClass` //without// any of the generated
   constraints being used inside an implication, which made GHC
   incorrectly believe the unification variables were untouchable.
 * Even worse, we were using the generated unification variables from
   `inferConstraintsDAC` in every single iteration of `simplifyDeriv`.
   In #14933, however, we have a scenario where we fill in a
   unification variable with a skolem in one iteration, discard it,
   proceed on to another iteration, use the same unification variable
   (still filled in with the old skolem), and try to unify it with
   a //new// skolem! This results in an utter disaster.

 The root of both these problems is `inferConstraintsDAC`. This patch
 fixes the issue by no longer generating unification variables
 directly in `inferConstraintsDAC`. Instead, we store the original
 variables from a generic default type signature in `to_metas`, a new
 field of `ThetaOrigin`, and in each iteration of `simplifyDeriv`, we
 generate fresh meta tyvars (avoiding the second issue). Moreover,
 this allows us to more carefully fine-tune the `TcLevel` under which
 we create these meta tyvars, fixing the first issue.

 Test Plan: make test TEST="T14932 T14933"

 Reviewers: simonpj, bgamari

 Reviewed By: simonpj

 Subscribers: rwbarton, thomie, carter

 GHC Trac Issues: #14932, #14933

 Differential Revision: https://phabricator.haskell.org/D4507
 }}}

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