inconsistent .hi file error gets ignored

[duncan]

[20 of 20] Compiling Main             ( ./Main.hs, dist/build/cabal/cabal-tmp/Main.o )
The interface for `main:Hackage.Config'
Declaration for savedConfigToConfigFlags
Unfolding of Hackage.Config.savedConfigToConfigFlags:
  Can't find interface-file declaration for variable Distribution.Simple.Setup.a401
    Probable cause: bug in .hi-boot file, or inconsistent .hi file
    Use -ddump-if-trace to get an idea of which file caused the error
Linking dist/build/cabal/cabal ...
dist/build/cabal/cabal-tmp/Hackage/Config.o: In function `sfsu_info':
(.text+0x70cc): undefined reference to `Cabalzm1zi3zi3_DistributionziSimpleziSetup_a401_closure'
dist/build/cabal/cabal-tmp/Hackage/Config.o: In function `rf7U_closure':
(.data+0xf28): undefined reference to `Cabalzm1zi3zi3_DistributionziSimpleziSetup_a401_closure'
collect2: ld returned 1 exit status

Now, the inconsistent .hi file was entirely my fault. However note that ghc --make did not stop at the error! It continued and tried to link.

This is bad because sometimes linker errors are very long and a user might loose the real source of the error.

The error gets raised in iface/TcIface.lhs by importDecl. The uses of that function look like they are translating the error into failure in other monads ok. It's not immediately obvious at what point in the propagation of this error it gets ignored and linking continues irrespective.

It should not be too hard to reproduce I hope. Generating inconsistent .hi files is fairly easy to do. In this case I just built cabal-install against an existing Cabal. Then rebuilt and re-registered a slightly changed Cabal lib. Then did another build of cabal-install without cleaning first.

[simonmar]

I'm not sure that "fixing" this by having the compilation fail is the right thing to do. GHC in one-shot mode is working on the assumption that the dependencies of the current module are up-to-date, and it is the user's responsibility to get that right. Given this assumption, GHC buries the code that typechecks interface declarations into thunks that might be evaluated at any time, so to have one of these throw an exception might lead to any number of strange and hard-to-reproduce problems - we might be half-way through some IO operation, and who knows what will happen if we abort.

Arguably you're getting strange and hard-to-reproduce problems anyway, and it might be better to fail earlier. It just scares me a bit.