[PATCH] Retry building modules that were compiled by other instances and are out-of-date

[Ben Langmuir]

When another clang instance builds a module, it may still be considered “out of date” for the current instance in a couple of cases*.  This patch prevents us from giving spurious errors when compilers race to build a module by allowing the module load to fail when the pcm was built by a different compiler instance.  Progress is still guaranteed because whichever compiler wins the race will not retry the module build. To know for sure whether the module was built by the current compiler instance, the module load is done within the scope of the LockFileManager object.  That only marginally increases the critical section, and only impacts compilers that are racing to *build* the module, not ones that subsequently try to load it.

* Cases where a module can be out of date despite just having been built:

1) There are different -I paths between invocations that result in finding a different module map file for some dependent module.  This is not an error, and should never be diagnosed.

2) There are file system races where the headers making up a module are touched or moved. Although this can sometimes mean trouble, diagnosing it only during a build-race is worse than useless and we cannot detect this in general.  It is more robust to just rebuild.  This was causing spurious issues in some setups where only the modtime of headers was bumped during a build.


Ben

-------------- next part --------------
A non-text attachment was scrubbed...
Name: out-of-date.patch
Type: application/octet-stream
Size: 4335 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20140617/c9e421fd/attachment.obj>