[PATCH] D30882: Add a callback for __has_include and use it for dependency scanning

[Daniel Dunbar via Phabricator via cfe-commits]

ddunbar added a comment.

In https://reviews.llvm.org/D30882#1074822, @dexonsmith wrote:

> I don't think this is quite right.  I know at least `make`-based incremental builds wouldn't deal well with this.


This is actually not a novel problem w.r.t. this patch. The exact same situation comes up with Makefile-included .d files and when one of the referenced headers is removed.

This is typically solved somewhere in the build system, for example Make has `-include`, and Ninja and llbuild have explicit support for this situation.

I agree we might want to tread cautiously on how we change the .d output, but in this case I think it might be safe.

If we decide this isn't safe, then we may want to consider a new flag which tracks *all* anti-dependencies (file's for which Clang checked existence but did not exist), and include that here. The major concern with that approach is it is a much larger list, and while it would support being substantially more correct, it is also well beyond what people currently expect out of the build system + compiler generated deps approaches.

> Given t.cpp:
> 
>   #if __has_include("missing.h")
>   #endif
> 
> 
> t.d will be:
> 
>   t.o: missing.h
> 
> 
> Since the build system doesn't know how to generate missing.h, when t.cpp changes the build system will stop dead in its tracks.
> 
> Knowing the list of files that are //potential// inputs to `t.o` seems useful, but we should probably do that under a separate flag.  And if it's a separate flag, we might consider giving it a better name than `-MF`...


https://reviews.llvm.org/D30882