#14596: Remove uses of unsafeGlobalDynFlags for state hack -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4265 Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj):
It seems like the logical place to put this is as a flag in TyCon.
Yes... * The flag is only needed in `PrimTyCon` * And only used for `statePrimTyCon` (see `Id.isStateHackType`) The trouble is, if `statePrimTyCon` is dependent on `DynFlags`, it can't be top-level defines (as it is now). Does that matter? Turns out that `statePrimTyCon` is used * In `MkId.runRWId`. I think I can elimiante this top-level Id altogether * In `TysPrim.mkStatePrimTy`... * ...which in turn is used in `PrelRules.seqRule`. That is easy to elminate; I'll submit a patch shortly. * ...and `TysPrim.realWorldStatePrimTy` and `MkId.realWorldPrimId`. This is a bit harder; it they are used in: * a bunch of cases in `DsCCall`, but there is a monad to hand there, so that's easy to fix. * a couple of places in `eqType realWorldStatePrimTy`, but that doesn't need the tycon, only the unique * in `CorePrep` and `ByteCodeGen` where we are inlining `runRWId`. I'm sure these would be do-able because we have an argument of type `State#` so the relevant `TyCon` is in there. In short, I think this could be done with minimal plumbing. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/14596#comment:3 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler