ghc --make aims to make compilation behave correctly and produce up-to-date, no matter whether it completes or is interrupted (e.g. with Ctrl+C) and later resumed

At no point should interrupting a build and running it again produce "less correct" outputs than running it to the end; specifically interrupting shouldn't result in necessary build steps to be "forgotten".

However, this seems to be the case with the [TH] check introduced in #481 (closed).

Minimal test case with 3 files: https://github.com/nh2/th-recomp-test

Good behaviour when running without interrupting:

% touch A.hs && ~/.stack/programs/x86_64-linux/ghc-8.0.1/bin/ghc --make Main.hs           
[1 of 3] Compiling A                ( A.hs, A.o )
[2 of 3] Compiling B                ( B.hs, B.o ) [TH]
[3 of 3] Compiling Main             ( Main.hs, Main.o ) [TH]
Linking Main ...

Bad behaviour when interrupting and running again:

% touch A.hs; timeout 0.1 ~/.stack/programs/x86_64-linux/ghc-8.0.1/bin/ghc --make Main.hs; ~/.stack/programs/x86_64-linux/ghc-8.0.1/bin/ghc --make Main.hs
[1 of 3] Compiling A                ( A.hs, A.o )
[2 of 3] Compiling B                ( B.hs, B.o ) [TH]
Linking Main ...

As you can see, when interrupting, the step Compiling Main ( Main.hs, Main.o ) [TH] went missing.

This suggests to me that either:

• the [TH]s are unnecessary in the first place (unlikely and I buy into the reason explained by #481 (closed) that changed values may be picked up by TH in higher-level modules)
• the resumed ghc --make invocation may potentially produce wrong / not-up-to-date outputs (most likely)
• re-running somehow retrieves the information that in fact recompiling Main is not necessary for a correct build (if this is the case, then I'd really like to know how that works and we should document it, likely also try to use that way to avoid recompiling Main in the uninterrupted run)