EPA : ghc-exactprint logistics
When the exact print annotations were initially brought in, they were accompanied by a series of tests.
But these tests did not exercise the actual intended usage of the annotations, which took place in the
ghc-exactprint
library, hosted separately on github.
Historically, there has been a process which kicks off around when a new GHC release branch is cut to add support
for the pending release to the ghc-exactprint
library. This includes generating issues on GHC when it is found that
the annotations need to be tweaked to properly round trip the extensive test suite.
Now that the exact print annotations (EPA's) are in the GHC ParsedSource
(since GHC 9.2.1), there is a
full-functionality source code round tripper in the GHC source tree, under ../utils/check-exact
.
But the ghc-exactprint
library has been updated separately from the one in GHC, and published to hackage.
At the same time, the one in GHC has been updated to keep track of the ongoing changes to GHC.
This means ghc-exactprint
is in a similar situation to haddock, in that changes to GHC require changes to
ghc-exactprint
, but it is (currently) published separately from GHC.
Here are some options as to how to proceed, and I am sure there are other ways of doing it too, hence this issue
- Status Quo, continue as before.
In practical terms, this means creating a branch for GHC head on the ghc-exactprint library, and merging in the changes from GHC head. Once this branch is stable, it gets merged back into the GHC utils/check-exact version, ready for the next round.
- Similar to haddock. ghc-exactprint becomes something inside the GHC source
This means utils/check-exact
becomes a thin driver over the main library, which must then be kept up to date.
Having experienced the friction of landing MRs on haddock this does not feel like a very good solution.
- Some sort of split of ghc-exactprint, into a library part fully inside the GHC source, and the other parts still inside the github repo.
Any other suggestions?