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 |