Expose --no-automatic-time-samples in GHC.RTS.Flags API

[mpickering]

GHC MR: https://gitlab.haskell.org/ghc/ghc/-/merge_requests/11916

In GHC MR !11424 a new RTS flag was added --no-automatic-time-samples.

Therefore we should also modify GHC.RTS.Flags in the same manner so that users can query whether this option is set from their programs, and keep GHC.RTS.Flags up to date with the implemented RTS flags.

[mpickering]

Is there anything which can be done to move this issue forwards? It seems that we should keep GHC.RTS.Flags up to date with the flags implemented by the RTS.

[Bodigrim]

Technically adding a record field is a breaking change, but given how obscure GHC.RTS.Flags is...

ProfFlags are used only in handful of places throughout entire Hackage: https://hackage-search.serokell.io/?q=%5CbProfFlags. None of them will be broken by the change.

Thus I'm content to vote in favor. Dear CLC members, any more opinions before we vote?

[tomjaguarpaw]

It seems fine to me. If GHC's interface changes then we need to make the corresponding change to anything that represents its interface. Ultimately though, given that this is a GHC-only concern, I'd love to see this functionality migrated into a package under the sole purview of GHC HQ.

[Bodigrim]

Dear CLC members, let's vote on the proposal to extend GHC.RTS.Flags to reflect faithfully RTS flags, including recently added one --no-automatic-time-samples. The MR is available at https://gitlab.haskell.org/ghc/ghc/-/merge_requests/11916 and boils down to extending data ProfFlags with startTimeProfileAtStartup :: Bool.

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

---

+1 from me.

[tomjaguarpaw]

+1

---

I risk sounding monotonous and saying things redundantly, but I'll reiterate anyway that these kinds of GHC configuration types should be in a GHC-internal module in the future.

EDIT: Actually I shouldn't say "internal". It's up to GHC HQ whether they expose these from a package that they intend to keep stable (I encourage them to do so), it just shouldn't be base, because they are deeply linked to GHC implementation details.

[velveteer]

+1

[parsonsmatt]

+1

[angerman]

+1

[mpickering]

@tomjaguarpaw I think we are in agreement there, and if you or another CLC member would like to open a proposal to move GHC.RTS.Flags out of base then I think GHC developers would support that.

[Bodigrim]

Thanks all, that's enough votes to approve.