Module compilation order improvement with GHC 9.4

1

I just found out that GHC 9.4 seems to have brought a major improvement (for me at least):

If I have diamond dependencies Main.hs → A.hs, B.hs → Lib.hs, and I change Lib.hs breaking both A and B, ghc --make now tries compiling both A and B, showing errors for both. It used to be that ghc --make would switch between trying to compile A and B, making iteration very painful.

So, big thanks to the GHC team for addressing this!

I couldn’t really make this out in the changelog, was it a side-effect of the multiple home module work?

(I ran across this trying to reproduce cabal issue Nondeterministic build order makes iterating painful · Issue #8215 · haskell/cabal · GitHub to see about reporting it against GHC.)

7 Likes
2

In 9.2.* there is the --keep-going flag which also does as you describe. We made some significant changes to the driver in 9.4 and decided that the --keep-going default was better.

8 Likes
3

So the flag is -fkeep-going, and indeed I get (sort of) the same behaviour with 9.2 when I pass that flag. “Sort of” because 9.4 also has a more stable order – with 9.2 and -fkeep-going, ghc switches between the compilation order Lib, B, A and Lib, A, B as I make changes.

It seems that -fno-keep-going doesn’t revert to the old behaviour, should that be considered a bug?

1 Like