#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