[clang] [clang][Modules] Adding Specific Diagnostics when a Finalized PCM is Out-of-date due to Input File Changes (PR #209857)

[Qiongsi Wu via cfe-commits]

qiongsiwu wrote:

> > If there are concurrent modifications of the input headers while the modules are getting build, I think this error will be triggered.
> 
> > I think for this particular case, this diagnostic is good enough, as it spells out the exact header that is modified to debug the potential race.
> 
> Given our prior experience in this area, that has not been the case, though. It's been logic bugs and saving state that went stale in a non-racy but still in a way that breaks our assumptions (e.g., negative stat caching). This also happens much more often when there's a pre-populated module cache. Or maybe I'm misunderstanding what cases `pcm_not_dropped` was intended to capture? In my opinion, when the compiler is in the position to implicitly build a module (therefore, the build system & user are not in charge of creating PCMs), this diagnostic is not straightforward because it should be able to rebuild the module, unlike when this happens e.g. precompiled headers, which is driven by the build system. We should still keep the explicit error about the problematic input file, no disagreement there.

Ok! I added a note specifically for the input change case to indicate that there may be a compile bug. 

https://github.com/llvm/llvm-project/pull/209857