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 _______________________________________________ cfe-commits mailing list [email protected] https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
