ghc: make sure top level exposed GHC is always host->target

See the added comment in all-packages.nix for a more detailed
explanation. This makes the top-level GHC different from
haskellPackages.ghc (which is build->host and used for building the
package set), but more consistent with gcc, gnat etc.

Specifically, pkgsCross.${platform}.buildPackages.ghc will now be a
cross-compiler instead of a native build->build compiler.

Since this change has a slight chance of being disruptive, add a note to
the changelog.

nixos/doc/manual/from_md/release-notes/rl-2205.section.xml

@@ -24,8 +24,29 @@
   </section>
   <section xml:id="sec-release-22.05-incompatibilities">
     <title>Backward Incompatibilities</title>
-    <para>
-    </para>
+    <itemizedlist spacing="compact">
+      <listitem>
+        <para>
+          <literal>pkgs.ghc</literal> now refers to
+          <literal>pkgs.targetPackages.haskellPackages.ghc</literal>.
+          This <emphasis>only</emphasis> makes a difference if you are
+          cross-compiling and will ensure that
+          <literal>pkgs.ghc</literal> always runs on the host platform
+          and compiles for the target platform (similar to
+          <literal>pkgs.gcc</literal> for example).
+          <literal>haskellPackages.ghc</literal> still behaves as
+          before, running on the build platform and compiling for the
+          host platform (similar to <literal>stdenv.cc</literal>). This
+          means you don’t have to adjust your derivations if you use
+          <literal>haskellPackages.callPackage</literal>, but when using
+          <literal>pkgs.callPackage</literal> and taking
+          <literal>ghc</literal> as an input, you should now use
+          <literal>buildPackages.ghc</literal> instead to ensure cross
+          compilation keeps working (or switch to
+          <literal>haskellPackages.callPackage</literal>).
+        </para>
+      </listitem>
+    </itemizedlist>
   </section>
   <section xml:id="sec-release-22.05-notable-changes">
     <title>Other Notable Changes</title>

nixos/doc/manual/release-notes/rl-2205.section.md

@@ -10,4 +10,16 @@ In addition to numerous new and upgraded packages, this release has the followin
 
 ## Backward Incompatibilities {#sec-release-22.05-incompatibilities}
 
+* `pkgs.ghc` now refers to `pkgs.targetPackages.haskellPackages.ghc`.
+  This *only* makes a difference if you are cross-compiling and will
+  ensure that `pkgs.ghc` always runs on the host platform and compiles
+  for the target platform (similar to `pkgs.gcc` for example).
+  `haskellPackages.ghc` still behaves as before, running on the build
+  platform and compiling for the host platform (similar to `stdenv.cc`).
+  This means you don't have to adjust your derivations if you use
+  `haskellPackages.callPackage`, but when using `pkgs.callPackage` and
+  taking `ghc` as an input, you should now use `buildPackages.ghc`
+  instead to ensure cross compilation keeps working (or switch to
+  `haskellPackages.callPackage`).
+
 ## Other Notable Changes {#sec-release-22.05-notable-changes}

pkgs/top-level/all-packages.nix

@@ -12066,7 +12066,15 @@ with pkgs;
   # current default compiler is”, if you bump this:
   haskellPackages = dontRecurseIntoAttrs haskell.packages.ghc8107;
 
-  inherit (haskellPackages) ghc;
+  # haskellPackages.ghc is build->host (it exposes the compiler used to build the
+  # set, similarly to stdenv.cc), but pkgs.ghc should be host->target to be more
+  # consistent with the gcc, gnat, clang etc. derivations
+  #
+  # We use targetPackages.haskellPackages.ghc if available since this also has
+  # the withPackages wrapper available. In the final cross-compiled package set
+  # however, targetPackages won't be populated, so we need to fall back to the
+  # plain, cross-compiled compiler (which is only theoretical at the moment).
+  ghc = targetPackages.haskellPackages.ghc or haskell.compiler.ghc8107;
 
   cabal-install = haskell.lib.compose.justStaticExecutables haskellPackages.cabal-install;