This is a meta-ticket about the avoidance of mutable global state in GHC (DynFlags, HscEnv, etc.). Many functions implicitly access DynFlags to query command line options, package state, linker state, etc. making the code not modular.

As a stronger motivation: I want to fix #14335 (support for compiler plugins with cross-compilation). It should have been pretty straightforward to use two package states instead of one (one for the host compiler and another for the target code). Sadly this isn't currently possible because the package state stored in DynFlags is accessed very indirectly (e.g. to get the effective wired-in unit ids on disk when pretty-printing messages for the user, etc.). There are a lot of other examples of this kind.

All the work done in this direction will be beneficial to make GHC multi-target, multi-session and to improve cross-compilation support (cf https://github.com/hsyl20/ghc-cross-compilation for what we would like to improve).

Tasks:

• Pretty printer

  • Remove DynFlags from pretty-print SDocContext: #10143 !3534 (closed)
  • Remove unsafeGlobalDynFlags #14597
  • Add SDocContext instead of directly accessing DynFlags in SDoc: !2612 (closed)
  • Don't access the (target) package state when pretty-printing UnitId, Module, etc.: !2941 (closed)
  • Use Platform instead of DynFlags in code generators: !2810 (closed) !2855 (closed) !2869 (closed) !2871 (closed) !2900 (closed) !3216 (closed) !2964 (closed) !3367
  • Fix handling of -dppr-debug: !2910 (closed)
  • Remove Outputable instances for things that need some context to be printed
  • Fix binary blob handling (GHC.CmmToAsm.Ppr.pprBytes): !2959 (closed)

• Loader/linker

  • Abstract external and internal interpreters instead of querying -fexternal-interpreter flag: !2730 (closed) !2834 (closed)
  • Support compiler plugins with cross-compilation #14335