Tooling-friendly ModSummary

[Edward Z. Yang]

Hello Alan,

SPJ and I both think that GhcMake is well overdue for a rewrite.
But it's not altogether obvious what the rewrite should look like.
I've made some remarks here: https://gist.github.com/ezyang/50004e0f842eec5848acad5cf1c22240

I'm OK with small, incremental changes that make tooling's life better.
But adding renamed/typechecked ASTs is almost certainly the wrong
thing to do.  The ModSummary is produced by looking at an hs file
and doing the bare minimum processing to get the import graph.

The way the pipeline works is a ModSummary is eventually turned into a
HomeModInfo by the typechecking process. So one possibility is that
if it is requested (retaining renamed, typechecked ASTs increases
memory consumption for clients that don't need it) the things you want
could be stashed in HomeModInfo.  So you'd probably augment
FrontendResult to return the information you need, and then
hscIncrementalCompile to stick it in HomeModInfo.

Things to be careful about:

- You will NOT get this info if you load the HomeModInfo from
  disk rather than compile it directly.  I am assuming that you
  have a way to convince 'load' to rebuild; I don't actually
  know how to do this.

- We don't want to save this info by default; it will increase
  memory usage for anyone who doesn't need it (e.g., ghc --make)

Hope that helps,
Edward

Excerpts from Alan & Kim Zimmerman's message of 2016-09-05 20:27:26 +0200:
> At the moment the standard way to use the GHC API is something like
> 
>                         _ <- load LoadAllTargets
>                         modSum <- getModSummary mn
>                         p <- parseModule modSum
> 
> And likewise if renamed or typechecked ASTs are needed.
> 
> But the `load` step already does all those phases.
> 
> So, would there be any objection to modifying the ModSummary to possibly
> retain those artifacts, configurable via a DynFlag?
> 
> I would expect the flag would default to retaining none, but could then
> either provide for returning all artifacts, or just for the targets
> explicitly listed in the `setTargets` call (i.e. not the full `depanal`
> result).
> 
> Regards
>   Alan