This is an archive of the discontinued LLVM Phabricator instance.

Modules: add command line option fmodules-disable-diagnostic-validation to disable validation of the diagnostic options when loading the module
ClosedPublic

Authored by manmanren on Jul 25 2016, 1:01 PM.

Details

Summary

With PCH+Module, sometimes compiler gives a hard error:
"Module file ‘<some-file path>.pcm' is out of date and needs to be rebuilt"

This happens when we have a PCH importing a module and the module gets overwritten by another compiler instance after we build the pch (one example is that both compiler instances hash to the same pcm file but use different diagnostic options). When we try to load the pch later on, the compiler notices that the imported module is out of date (modification date, size do not match) but it can't handle this out of date pcm (i.e it does not know how to rebuild the pch).

This patch introduces a new command line option so for PCH + module, we can turn on this option and if two compiler instances only differ in diagnostic options, the latter instance will not invalidate the original pcm.

Diff Detail

Repository
rL LLVM

Event Timeline

manmanren updated this revision to Diff 65405.Jul 25 2016, 1:01 PM
manmanren retitled this revision from to Modules: add command line option fmodules-disable-diagnostic-validation to disable validation of the diagnostic options when loading the module.
manmanren updated this object.
manmanren added a reviewer: benlangmuir.
manmanren added a subscriber: cfe-commits.
benlangmuir edited edge metadata.Jul 25 2016, 2:47 PM

We need to add this option to the module hash (see getModuleHash - we already add a bunch of other HSOpts there). Otherwise the pcm could still be rewritten by a compilation that doesn't use a PCH, and then it would be out of date because of the timestamp instead of the diagnostic options.

We need to add this option to the module hash (see getModuleHash - we already add a bunch of other HSOpts there). Otherwise the pcm could still be rewritten by a compilation that doesn't use a PCH, and then it would be out of date because of the timestamp instead of the diagnostic options.

I was thinking that for a project using PCH+Module, all clang invocations will be using -fmodules-disable-diagnostic-validation, so if only the diagnostic options change, they will hash to the same pcm file but the compiler will not regenerate and overwrite the existing pcm file. So when we load the pch, the time stamp etc will match and the compiler will not throw out-of-date error.

We can definitely hash the option HSOpts.ModulesValidateDiagnosticOptions in getModuleHash. But I don't quite get the reason you give here :)
the pcm could still be rewritten by a compilation that doesn't use a PCH, and then it would be out of date because of the timestamp instead of the diagnostic options

"a compilation that doesn't use a PCH", is that a different project? And we have two projects building in parallel? Just to make sure I understand.

Thanks!
Manman

the pcm could still be rewritten by a compilation that doesn't use a PCH, and then it would be out of date because of the timestamp instead of the diagnostic options

"a compilation that doesn't use a PCH", is that a different project? And we have two projects building in parallel? Just to make sure I understand.

Two different projects (or targets, or whatever), but they don't even have to build at the same time. They just have to share a cache. Suppose you have a project A with a PCH and -fmodules-disable-diagnostic-validation. Suppose you have another project B that does not use this flag, and does not have a PCH. With this patch, A and B can share a module cache.

A builds a PCH that depends on some module X -- OK
B builds with -Werror. Rebuilds X.pcm -- OK

Now suppose we build A again because of some change: it can't build because X.pcm changed, but we haven't rebuilt the PCH.

the pcm could still be rewritten by a compilation that doesn't use a PCH, and then it would be out of date because of the timestamp instead of the diagnostic options

"a compilation that doesn't use a PCH", is that a different project? And we have two projects building in parallel? Just to make sure I understand.

Two different projects (or targets, or whatever), but they don't even have to build at the same time. They just have to share a cache. Suppose you have a project A with a PCH and -fmodules-disable-diagnostic-validation. Suppose you have another project B that does not use this flag, and does not have a PCH. With this patch, A and B can share a module cache.

A builds a PCH that depends on some module X -- OK
B builds with -Werror. Rebuilds X.pcm -- OK

Now suppose we build A again because of some change: it can't build because X.pcm changed, but we haven't rebuilt the PCH.

Got it, I will update the patch!

Manman

manmanren updated this revision to Diff 65449.Jul 25 2016, 5:19 PM
manmanren edited edge metadata.

Addressing Ben's comments

benlangmuir accepted this revision.Jul 26 2016, 9:39 AM
benlangmuir edited edge metadata.

LGTM

This revision is now accepted and ready to land.Jul 26 2016, 9:39 AM
This revision was automatically updated to reflect the committed changes.