No `Settings` in `DynFlags`
The two commits should describe themselves pretty well:
Settingsinto smaller structs
As far as I can tell, the fields within
Settingsaren't intrinsically related. They just happen to be initialized the same way (in particular prior to the rest of
DynFlags), and that is why they are grouped together.
Settings, however, there are groups of settings that clearly do share something in common, regardless of how they anything is initialized.
In the spirit of GHC being a library, where the end consumer may choose to initialize this configuration in arbitrary ways, I made some new data types for those groups internal to
Settings, and used them to define
Settingsinstead. Hopefully this is a baby step towards a general decoupling of the stateful and stateless parts of GHC.
After the previous commit,
Settingsis just a thin wrapper around other groups of settings. While
Settingsis used by GHC-the-executable to initalize
DynFlags, in principle another consumer of GHC-the-library could initialize
DynFlagsa different way. It therefore doesn't make sense for
DynFlagsitself (library code) to separate the settings that typically come from
Settingsfrom the settings that typically don't.
There's also an immediate motivation in that speed up !959 I need to cache some former CAFs in
DynFlags. The best way to do so would be make a
PlatformWithCache containing the cache key (
Platform) and cache values to make cache invalidation bugs less likely. (
PlatformWithCache is essentially a view at a single argument into the memo table for a memoized function.) But
Platform is in
PlatformWithCache has no place in
The GHCi changes are somewhat more than the minimal because I don't find it very forward-looking to assuming the formerly-in-
Settings options within
DynFlags are static. Keeping track of the original
DynFlags at the start of the GHCi session will surely produce an honest diff.
Please take a few moments to verify that your commits fulfill the following:
- are either individually buildable or squashed
have commit messages which describe what they do
(referring to Notes and tickets using
#NNNNsyntax 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