Skip to content
  • Rodrigo Mesquita's avatar
    Hardwire a better unit-id for ghc · 3fdb18f8
    Rodrigo Mesquita authored and Marge Bot's avatar Marge Bot committed
    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, 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.Settings.Config` whose value is the new unit-id.
        (2.1) `GHC.Settings.Config` is generated by Hadrian
        (2.2) and also by cabal through `compiler/Setup.hs`
    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 and check compatibility when loading plugins.
    Note that we also ensure that ghc's unit key matches unit id both when
    hadrian or cabal builds ghc, and in this way we no longer need to add
    `ghc` to the WiringMap.