Failure to recompile when #include file is created earlier on include path

Originally discovered when trying to improve Hadrian, for context see: https://github.com/snowleopard/hadrian/issues/247#issuecomment-222317602

If you create a file Main.hs

#include "Test.h"
main = print message

And a file a/Test.h

message = 1

Then run and compile with ghc --make -XCPP -Ib -Ia Main.hs it compiles and runs properly, printing 1. Changing a/Test.h to message = 2 then running ghc rebuilds and prints 2. Creating a fresh b/Test.h with message = 3 does not cause ghc to recompile, and thus incorrectly still prints 2. Touching Main.hs causes recompilation, and then the correct header file is picked up, resulting in 3 being printed.

changed weight to 5

added Tbug Trac import labels

changed the description

Trac metadata

Trac field	Value
Component	Compiler → Driver

added driver label

mentioned in commit f91d87df

assigned to @ezyang

Fix is easy: we need to track files which are expected to be non-existent; starting with hpm_src_files all the way to mi_usages. I'll do a patch.

UPDATE: Actually, this is a bit harder because I have to figure out how to get the preprocessor to spit out search paths in a useful way...

It's unclear how to get the preprocessor to divulge what paths were searched. However, if we can get this information, then it should be relatively easy to track file non-existence in usages. The recipe for getting the preprocessor to produce this information is of general interest; I've filed a bug with Shake to see if there's a good way to get the info out of cpp: https://github.com/ndmitchell/shake/issues/463

added broken test label

added Pnormal label

unassigned @ezyang

added to epic &2