Hardwire a better unit-id for ghc
Hardwire a better unit-id for ghc
Previously, the unit-id of ghc-the-library was fixed as ghc
.
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 (closed), a reinstallable ghc
whose unit-id is fixed
to 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 (closed)