Variant of runGhc which accepts prelude for setting up DynFlags

One of the long-standing awkwardness of using the GHC API is the need to call setSessionDynFlags *again* after you finish setting up the DynFlags with all the parameters you care about. Furthermore, you must run getSessionDynFlags AGAIN in order to get the "most up-to-date" version of DynFlags, because the package initialization process twiddles with values in DynFlags.

That's terrible.

What we would like to do is set an invariant that there will be NO non-user changes to DynFlags. That means pkgDatabase, pkgState and thisPackage, which are twiddled by initPackages, really *ought not* to live in DynFlags. This would also fix a pile of nattering about with copying these values between the interactive DynFlags and normal DynFlags.

However, there is a problem with trying to do this: most of the functions in Packages assume only a DynFlags is available. And you can basically assume that you'll have a DynFlags everywhere; not so much for HscEnv. So actually fixing this would require a lot of code heaving around that I'm not too interested in at the moment.

There is, however, something we can do that will make people's life's better: a new version of runGhc which also accepts a function from GhcMonad m => DynFlags -> m DynFlags which is responsible for taking the DynFlags and configuring it to some suitable state. Whatever is returned, GHC can then make the final modifications (e.g. filling in those fields) and finally setting it as the DynFlags in the HscEnv, and ALSO updating the unsafe global DynFlags.

This is not too hard to do. But is it the right thing to do? I'd like to know.

Trac metadata

Trac field	Value
Version	7.11
Type	Bug
TypeOfFailure	OtherFailure
Priority	normal
Resolution	Unresolved
Component	Compiler
Test case
Differential revisions
BlockedBy
Related
Blocking
CC
Operating system
Architecture