Skip to content
GitLab
Projects Groups Topics Snippets
  • /
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
  • Register
  • Sign in
  • GHC GHC
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributor statistics
    • Graph
    • Compare revisions
    • Locked files
  • Issues 5.5k
    • Issues 5.5k
    • List
    • Boards
    • Service Desk
    • Milestones
    • Iterations
  • Merge requests 633
    • Merge requests 633
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Artifacts
    • Schedules
    • Test cases
  • Deployments
    • Deployments
    • Releases
  • Packages and registries
    • Packages and registries
    • Model experiments
  • Analytics
    • Analytics
    • CI/CD
    • Code review
    • Insights
    • Issue
    • Repository
  • Wiki
    • Wiki
  • Snippets
    • Snippets
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar
  • Glasgow Haskell CompilerGlasgow Haskell Compiler
  • GHCGHC
  • Issues
  • #17957

Avoid direct access to compiler state

(See also the wiki page https://gitlab.haskell.org/ghc/ghc/-/wikis/Make-GHC-codebase-more-modular)

This is a meta-ticket about the avoidance of direct access to compiler state (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).

Three different but related goals regarding DynFlags:

  1. Make it clearer which bits of DynFlags are used where. Eg pass smaller record to SDoc. Ameliorates the symptoms of not having (2); and is generally a good idea.
  2. Stop making DynFlags depend on TcM etc. It should just be an abstract syntax tree. Move mutable state, caches &c, to Session (= HscEnv).
  3. Remove mutable state from DynFlags, and keep it somewhere else. But where? HscEnv?

Old Tasks:

  • Remove DynFlags from pretty-print SDocContext: #10143 (closed)
  • Remove unsafeGlobalDynFlags #14597
  • Add SDocContext instead of directly accessing DynFlags in SDoc
  • Don't access the (target) package state when pretty-printing UnitId, Module, etc.
  • Use Platform instead of DynFlags in code generators
  • Fix handling of -dppr-debug
  • Remove Outputable instances for things that need some context to be printed
  • Fix binary blob handling (GHC.CmmToAsm.Ppr.pprBytes)
  • Don't store state into DynFlags. Use HscEnv or another env instead.
    • !7829 (closed)
  • Remove DumpFlags from Logger (c.f. logHasDumpFlag). They must be passed in each subsystem configuration explicitly instead. [It is easier to do it that way after first untangling Logger and DynFlags]

Current tasks, making subsystems not use DynFlags and HscEnv:

A crude test is

git grep -l -E '(Driver.Session|DynFlags|dflags|HscEnv|hsc_env)' ':(exclude)compiler/GHC/Driver' compiler/

to find module in need of being fixed up.

Isolate DynFlags module by module, phase by phase in the compiler. we'll try to proceed in this ordering (deepest part of the compiler up) based on the log file in @doyougnu's previous comments in #20730.

C-- & STG

  • CmmToLlvm: merged: !7158 (closed)
  • Cmm: merged: !7199 (closed)
  • Cmm.Parser
    • No more DynFlags !8160 (merged)
    • No more StgToCmmConfig !8237
  • StgToCmm: merged: !7325 (closed)
  • Stg: merged: !7479 (closed)

Core optomizations

core-opt-modulegraph

Green modules

  • Core.Opt.Arity: !8177 (closed)
    • !8291 (closed) Follow up to make GHC.Driver.Config module.
  • Core.Opt.WorkWrap: !8294 (closed)
  • Core.Opt.LiberateCase: !8296 (closed)
  • GHC.Core.Opt remove some HscEnv !7515 (merged)

Purple modules

Can do punting on the monad, perhaps:

  • Core.Lint: !8293 (merged)
  • CoreToStg.Prep !7498 (merged)
  • CoreToStg

The monad issue:

  • #21611 Make CoreM just for plugins
    • !8341

Better to do after:

  • Make Core.Lint.Interactive: !8470 first commit
  • Core.Opt (a good many modules)
    • No HscEnv: !7845 (closed)
  • ... re-evaluate once here ...
  • Iface.Tidy !7836 (closed)
  • HsToCore
    • Coverage no HscEnv: !7467 (closed)
    • Usage no HscEnv: !8231 (closed)
    • No HscEnv: !7845 (closed)
    • Coverage no DynFlags: !7508 (merged)
    • Usage no HscEnv

Misc

Linker modules except for GHC.Linker.Loader seem like perhaps good "leaf" modules to tackle.

  • GHC.Linker
  • GHC.Linker.Dynamic
  • GHC.Linker.ExtraObj
  • GHC.Linker.Loader Probably best to skip
  • GHC.Linker.MacOS
  • GHC.Linker.Static
  • GHC.Linker.Static.Utils
  • GHC.Linker.Types
  • GHC.Linker.Unit: !8370 (closed)
  • GHC.Linker.Windows
Edited Jan 20, 2023 by Sylvain Henry
To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information
Assignee
Assign to
Time tracking