WIP: Begin to split compiler frontend and middle in driver --- includes !3204
Begin to split compiler frontend and middle in driver.
The compiler "frontend" is taken to be the parsing, renaming, and type checking steps, while the middle is the desugaring and simplifying steps.
The original motivation came from #14095, where we want to frontend vs middle work for smaller and more paralell rebuilds.
As, if not more, important, is the need to explore how to untangle the deriver for sake of maintainability, not new features. I don't know the destination. Here is a few points of exploration:
-
I do hope separating things into smaller piece that compose, rather than big piece that at highly conditional ("do this for GHCi, this for backpck, this for hs-boot", this for one-shot, etc.).
-
!1823 (merged) might have a regression in terms of dependencies from modules on instantiations, which could be solved by tracking resolved
Module
s rather than syntactic(Maybe FastString {-# library name #-}, ModuleName)
pairs. ButModSummary
is used in many different ways which makes this an unclear refactor, even allowing we parameterizedModSummary
or make more types. -
!935 (closed), which I earlier began but is also part to a GSOC proposal, also benefits from a
Unit
-aware --make, and likewise could benefit from the clearer use ofModSummary
and other data types.
None of these are solved/answered by this, but I believe it gets us closer.
-
are either individually buildable or squashed -
have commit messages which describe what they do (referring to Notes and tickets using #NNNN
syntax when appropriate) -
have added source comments describing your change. For larger changes you likely should add a Note and cross-reference it from the relevant places. -
add a testcase to the testsuite. -
replace this message with a description motivating your change
If you have any questions don't hesitate to open your merge request and inquire
in a comment. If your patch isn't quite done yet please do add prefix your MR
title with WIP:
.