Skip to content

Untracked implicit dependencies on GHC.Num.BigNat

Summary

Occasionally one of my local builds fails with an error message like this one:

ghc: panic! (the 'impossible' happened)
  GHC version 9.9.20230906:
        lookupGlobal
  ErrorWithoutFlag
    Failed to load interface for ‘GHC.Num.BigNat’.
    There are files missing in the ‘ghc-bignum-1.3’ package,
    try running 'ghc-pkg check'.
    Use -v to see a list of the files searched for.
  Call stack:
      CallStack (from HasCallStack):
        callStackDoc, called at compiler/GHC/Utils/Panic.hs:186:37 in ghc:GHC.Utils.Panic
        pprPanic, called at compiler/GHC/Tc/Utils/Env.hs:154:18 in ghc:GHC.Tc.Utils.Env
  CallStack (from HasCallStack):
    panic, called at compiler/GHC/Utils/Error.hs:511:29 in ghc:GHC.Utils.Error


Please report this as a GHC bug:  https://www.haskell.org/ghc/reportabug

At first report, the failing command was always building GHC.Utils.Containers.Internal.StrictPair. But since then, some other modules have become problematic, including base:GHC.IO.Encoding.Iconv, Data.Sum.Experimental, and Data.Tuple.Experimental.

Steps to reproduce

Check out a clean ghc master. Boot, configure, then run hadrian/build _build/stage1/compiler/build/GHC/Utils/Containers/Internal/StrictPair.o.

This will fail with a smaller "Failed to load interface" message, mentioning GHC.Tuple.Prim instead of GHC.Num.BigNat.

Diagnosis

Whenever GHC compiles a module, it tries to read the interface file for ghc-bignum:GHC.Num.BigNat so that it can use bigNatFromWordList# to generate code for any bigint literals the module may contain. It does this regardless of whether the module actually contains any such literals; only modules in the packages ghc-prim and ghc-bignum do not implicitly depend on ghc-bignum:GHC.Num.BigNat. The relevant compiler code is here. (This mechanism is an annoying hack, working around the fact that we do not currently have ByteArray# literals in Stg.)

The Note [Depend on GHC.Num.Integer] in GHC.Internal.Base describes the situation as well, and suggests that boot library modules should generally import GHC.Internal.Base or Prelude to avoid these build order problems. And that's a fine temporary workaround! But enforcement is spotty, especially since the build system problems from untracked dependencies tend to be intermittent. It would be much better to either make hadrian+ghc aware of this implicit dependency or to remove the need for this implicit dependency, so that GHC and boot library developers to add them manually.

(Of course, better still would be getting proper support for ByteArray# literals! Then we could remove the hacky implicit dependency entirely.)

There are a couple of other related untracked implicit dependencies; see also #24520.

Edited by Matthew Craven
To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information