• Ryan Scott's avatar
    Fix two pernicious bugs in DeriveAnyClass · 98930426
    Ryan Scott authored
    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
TcDerivUtils.hs 40.4 KB