Split `Backend` into multiple sum typeswip/maybe-backend

(What's the additive version of "factor"? :))

Preliminary step towards #20927 and #21034

I have wanted to do this for a while, and @nrnrnr's work convinced me I
should hurry up :) and do so.

I think enumerating "No backend" with actual backends is not good. We are very
far from having any nice notion of an "identity backend", and absent
that I cannot think of any other justification for the status quo.

`NoBackend` is kept as a pattern synonym so the code doesn't regress in
readability when there are no type annotation nearby.

Note this is a bare minimum refactor; I didn't make much of an
attempt to "prove" this was the right direction. But a few low-hanging
fruits nevertheless did arise:

 - `platformDefaultBackend` is guaranteed to return an actual backend.

 - In `GHC.Tc.Gen.Foreign`, `checkCOrAsmOrLlvmOrInterp` is dead code,
   because `checkCg` allows any foreign declaration with `NoBackend`.
   This makes sense to me: without a choice of the next pipeline stage
   committed to committed to, who's to say some constructor is outside
   its domain?

   `checkCg` now takes a `ActualBackend -> Validity` callback,
   demonstrating that `NoBackend` is handled separately.

This is enough to make me feel good I am not barking down the wrong
tree.

@nrnrnr's !7442 will end up touching many/most of the same lines that
this touches, but I think that is OK.

I am all for, downstream of `DynFlags`, trying to get rid of anything
looking at the `Backend` datatype, because we should support arbitrary
backends where are free to very those knobs however they like, fully
independently.

However, I don't thinking folding in `NoBackend` to our more "semantic"
representation of a backend (the new record) will make sense.
Conversely, I think the more we try to better structure what a backend
is/does, the more `NoBackend` would stick out like a sore thumb, ruining
our abstractions.

If we do this before `!7442`, we have the opportunity to use `Maybe
SemanticBackend` downstream to side-step those issues, but even that I
think will be somewhat temporary. As we continue to purge `DynFlags`
from the code base, I think we will increasingly separate code that
needs an actual backend from code that is agnostic. And the code that
agnostic I don't think should get a `Maybe SemanticBackend`, but rather
expose the knobs it would infer from the backend directly.

Why? This is the same argument as `checkCg`: if you haven't chosen a
backend yet, who is to say some choices are invalid? Not the
non-existent backend!  Conversely if we a backend requires a certain
choice made "upstream" in order for it to work, that that code should go
with the backend, not the upstream component. This preserves the
separation of concerns, and allows arbitrary backends to have arbitrary
policies.

1 files changed, 35 insertions, 21 deletions

diff --git a/compiler/GHC/Driver/Backend.hs b/compiler/GHC/Driver/Backend.hs
index 2642a2a9af..9f37f6c62a 100644
--- a/compiler/GHC/Driver/Backend.hs
+++ b/compiler/GHC/Driver/Backend.hs
@@ -1,8 +1,11 @@
 {-# LANGUAGE MultiWayIf #-}
+{-# LANGUAGE PatternSynonyms #-}
 
 -- | Code generation backends
 module GHC.Driver.Backend
-   ( Backend (..)
+   ( Backend
+   , pattern NoBackend
+   , ActualBackend (..)
    , platformDefaultBackend
    , platformNcgSupported
    , backendProducesObject
@@ -19,7 +22,7 @@ import GHC.Platform
 -- (producing machine code, producing ByteCode for the interpreter) and
 -- supporting different platforms.
 --
-data Backend
+data ActualBackend
    = NCG           -- ^ Native code generator backend.
                    --
                    -- Compiles Cmm code into textual assembler, then relies on
@@ -72,19 +75,30 @@ data Backend
                    --
                    -- See "GHC.StgToByteCode"
 
+   deriving (Eq,Ord,Show,Read)
 
-   | NoBackend     -- ^ No code generated.
-                   --
-                   -- Use this to disable code generation. It is particularly
-                   -- useful when GHC is used as a library for other purpose
-                   -- than generating code (e.g. to generate documentation with
-                   -- Haddock) or when the user requested it (via -fno-code) for
-                   -- some reason.
+-- | Sometimes we have a backend, and sometimes we do not.
+--
+-- Not inlining 'Nothing' into 'ActualBackend' will help lead towards things
+-- like e.g.
+--
+-- - Building for multiple backends at once, where we would switch from
+--   'Maybe ActualBackend' to 'Set ActualBackend', not 'Set (Maybe
+--   ActualBackend)'.
+--
+-- - Ensuring all backends can write to files. That would mean byte code can be
+--   written to a file (#21034), which makes 'ActualBackend' much more uniform.
+--   Conversely it's hard to imagine it would ever make sense for 'NoBackend' to
+--   write to a file!
+type Backend = Maybe ActualBackend
 
-   deriving (Eq,Ord,Show,Read)
+{-# COMPLETE NoBackend, Just #-}
+
+pattern NoBackend :: Backend
+pattern NoBackend = Nothing
 
 -- | Default backend to use for the given platform.
-platformDefaultBackend :: Platform -> Backend
+platformDefaultBackend :: Platform -> ActualBackend
 platformDefaultBackend platform = if
       | platformUnregisterised platform -> ViaC
       | platformNcgSupported platform   -> NCG
@@ -108,11 +122,11 @@ platformNcgSupported platform = if
 
 -- | Will this backend produce an object file on the disk?
 backendProducesObject :: Backend -> Bool
-backendProducesObject ViaC        = True
-backendProducesObject NCG         = True
-backendProducesObject LLVM        = True
-backendProducesObject Interpreter = False
-backendProducesObject NoBackend   = False
+backendProducesObject (Just ViaC)        = True
+backendProducesObject (Just NCG)         = True
+backendProducesObject (Just LLVM)        = True
+backendProducesObject (Just Interpreter) = False
+backendProducesObject NoBackend          = False
 
 -- | Does this backend retain *all* top-level bindings for a module,
 -- rather than just the exported bindings, in the TypeEnv and compiled
@@ -124,8 +138,8 @@ backendProducesObject NoBackend   = False
 -- When no backend is used we also do it, so that Haddock can get access to the
 -- GlobalRdrEnv for a module after typechecking it.
 backendRetainsAllBindings :: Backend -> Bool
-backendRetainsAllBindings Interpreter = True
-backendRetainsAllBindings NoBackend   = True
-backendRetainsAllBindings ViaC        = False
-backendRetainsAllBindings NCG         = False
-backendRetainsAllBindings LLVM        = False
+backendRetainsAllBindings NoBackend          = True
+backendRetainsAllBindings (Just Interpreter) = True
+backendRetainsAllBindings (Just ViaC)        = False
+backendRetainsAllBindings (Just NCG)         = False
+backendRetainsAllBindings (Just LLVM)        = False