Draft: deriving: Typecheck associated family instances before instance bindings
This is a significant overhaul of the way that deriving
clauses and
standalone deriving
declarations are typechecked. The highlights:
-
Standalone
deriving
declarations are located in the newDerivInstD
constructor ofClsInstDecl
, rather than as part of theDerivD
constructor ofHsGroup
. This move now means that standalonederiving
instance declarations are located alongside other forms of instance declarations, which makes it easier to perform SCC analysis on them, as they are now part of aTyClGroup
. -
Now that everything
deriving
-related lives inTyClGroup
s, we now typecheck all of the associated type family instances that are generated fromderiving
clauses/declarations first (intcTyClGroup
) before typechecking any of the generated instance bindings, which happen after all of theTyClGroup
s have been processed. Doing so is essential to ensuring that these associated type instances are in scope when needed to typecheck other code in laterTyClGroup
s, such as the failing examples seen in #23496. I have written an extensiveNote [Staging of deriving]
(previouslyNote [Staging of tcDeriving]
) to describe how everything works.
The second bullet point above involves quite a bit of churn in the expected output of several test cases. This is for two reasons:
-
The order in which things are printed with
-ddump-deriv
is now different, sincederiving
-related family instances are now generated earlier in the typechecker. -
If a test case errors out when typechecking a
deriving
-related family instance, then GHC will stop there before printing any errors involving the generated instance bindings. (Previously, both sorts of errors were printed simultaneously.) As such, some expected-to-fail test cases do not print out as many errors as before.
Fixes #23496.