Minor tweaks to GHC RTS flags exposed via base

[dcoutts]

As part of some GHC RTS refactoring and improvements related to the RTS I/O managers, we need to change an RTS flag. The GHC RTS flags are currently exposed via base in GHC.RTS.Flags. The types there reflect 1:1 the GHC RTS CLI flags. Thus these types are obviously tightly coupled to GHC and the GHC version.

The specific changes are:

• A new IoManagerFlag data type is exported via GHC.RTS.Flags
• The MiscFlags field ioManager field changes type from IoSubSystem to IoManagerFlag
• The IoSubSystem type is still re-exported from GHC.RTS.Flags but with a deprecation warning instructing people to import it from its "proper" place in GHC.IO.Subsystem
• The getIoManagerFlag function is no longer exported from GHC.RTS.Flags

Note that:

• The IoSubSystem type is still exported via GHC.IO.Subsystem, which is where it should be used from anyway.

Implementation

https://gitlab.haskell.org/ghc/ghc/-/merge_requests/9676

Impact

It is expected that the impact is minimal. It's very unusual for libraries or applications to use GHC.RTS.Flags at all, and those that do typically don't depend on all the details and the ioManager flag is a rather obscure feature.

A survey of https://hackage-search.serokell.io/?q=GHC.RTS.Flags reveals:

• 21 packages import/use GHC.RTS.Flags, all of them either
  1. use only specific imports, not including MiscFlags
  2. re-export things without depending on specifics
  3. do so generically, e.g. generic deriving or TH deriving (text-show, generics-sop, staged-gg
• IoSubSystem is imported by store (in its testsuite), streamly and streamly-core. These will be affected by the deprecation warning
• getIoManagerFlag is used only in base.

Migration

Follow the instructions on the deprecation warning for GHC.RTS.Flags.IoSubSystem and import it from GHC.IO.SubSystem instead.

Commentary

Longer term it would seem wise for GHC.RTS.Flags to not be exported from base at all since it is inherently GHC-specific and tightly coupled to internal details of the implementation. Perhaps like ghc-heap it needs its own package (since apparently the policy is that packages should not depend on ghc-internals directly).

[Bodigrim]

That's similar to #243 and #254, which we approved recently.

Dear CLC members, let's vote on the proposal to tweak GHC.RTS.Flags to account for new in-RTS I/O managers. The MR at https://gitlab.haskell.org/ghc/ghc/-/merge_requests/9676 is rather big, but only a small - and most trivial - part of it falls under CLC purview, namely changes to GHC.RTS.Flags.

@tomjaguarpaw @mixphix @hasufell @angerman @parsonsmatt @velveteer

---

+1 from me.

[parsonsmatt]

+1

[hasufell]

+1

[tomjaguarpaw]

+1

[angerman]

+1 🤞I didn't miss anything.

[Bodigrim]

Thanks all, that’s enough votes to approve.

[dcoutts]

Cheers folks.