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.