Hardwire a better unit-id for ghc
Previously, the unit-id of ghc-the-library was fixed as
This was done primarily because the compiler must know the unit-id of
some packages (including ghc) a-priori to define wired-in names.
However, as seen in #20742, a reinstallable
ghc whose unit-id is fixed
ghc might result in subtle bugs when different ghc's interact.
A good example of this is having GHC_A load a plugin compiled by GHC_B, where GHC_A and GHC_B are linked to ghc-libraries that are ABI incompatible. Without a distinction between the unit-id of the ghc library GHC_A is linked against and the ghc library the plugin it is loading was compiled against, we can't check compatibility.
This patch gives a slightly better unit-id to ghc (ghc-version) by
(1) Not setting -this-unit-id to ghc, but rather to the new unit-id (modulo stage0)
(2) Adding a definition to
GHC.Version whose value is the new unit-id.
This unit-id definition is imported by
GHC.Unit.Types and used to
set the wired-in unit-id of "ghc", which was previously fixed to "ghc"
The commits following this one will
improve the unit-id with a cabal-style package hash
ensure cabal-built ghcs also correctly use a better unit-id (and the package-key matches the unit-id)
and check compatibility when loading plugins.
When finished, should close #20742