Remove uses of unsafeGlobalDynFlags for state hack

Currently there are a variety of uses of the terrible unsafeGlobalDynFlags scattered about the compiler to implement -fno-state-hack. This global state makes parallel compilation unreliable and complicates API usage. Remove these uses.

Trac metadata

Trac field	Value
Version	8.2.1
Type	Task
TypeOfFailure	OtherFailure
Priority	normal
Resolution	Unresolved
Component	Compiler
Test case
Differential revisions
BlockedBy
Related
Blocking
CC
Operating system
Architecture

changed weight to 5

added Ttask Trac import labels

DemiMarie has a patch (Phab:D4265) implementing this. Unfortunately it's quite invasive.

On the call Simon proposed an alternate way forward: rather than making the decision of whether to apply the state hack during simplification, instead push the decision up to the typechecker. The State# tycon would carry whether or not it should be considered for the state hack. Simonpj will likely pop up here and fill in more details later.

Trac metadata

Trac field	Value
Differential revisions	- → D4265
CC	- → DemiMarie

It seems like the logical place to put this is as a flag in TyCon.

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.

mentioned in commit 10ed3198

mentioned in commit ff1544d6

added Pnormal label

It's not so easy, mkStatePrimTy is used in the generated primop code. E.g.

primOpInfo PrefetchValueOp0 = mkGenPrimOp (fsLit "prefetchValue0#")  [alphaTyVar, deltaTyVar] [alphaTy, mkStatePrimTy deltaTy] (mkStatePrimTy deltaTy)

mentioned in issue #18238

marked this issue as related to #18238

added The state hack label