No `Settings` in `DynFlags`
The two commits should describe themselves pretty well:
Break up
Settings
into smaller structsAs far as I can tell, the fields within
Settings
aren't intrinsically related. They just happen to be initialized the same way (in particular prior to the rest ofDynFlags
), and that is why they are grouped together.Within
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 defineSettings
instead. Hopefully this is a baby step towards a general decoupling of the stateful and stateless parts of GHC.
and then
Inline
Settings
intoDynFlags
After the previous commit,
Settings
is just a thin wrapper around other groups of settings. WhileSettings
is used by GHC-the-executable to initalizeDynFlags
, in principle another consumer of GHC-the-library could initializeDynFlags
a different way. It therefore doesn't make sense forDynFlags
itself (library code) to separate the settings that typically come fromSettings
from the settings that typically don't.
There's also an immediate motivation in that speed up !959 (closed) 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 Settings
, and PlatformWithCache
has no place in Settings
, only DynFlags
.
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.
CC @bgamari
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 #NNNN
syntax 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
title with WIP:
.