[PATCH] D20867: [PCH] Fix timestamp check on windows hosts.

[pierre gousseau via cfe-commits]

pgousseau added a comment.

> > On Linux, if the timestamp of a header file, included in the pch, is modified, then including the pch without regenerating it causes a fatal error, which is reasonable.

> 

> >  On Windows the check is ifdefed out, allowing the compilation to continue in a broken state.

> 

> >  The root of the broken state is that, if timestamps dont match, the preprocessor will reparse a header without discarding the pch data.

> 

> >  This leads to "#pragma once" header to be included twice.

> 

> >  The reason behind the ifdefing of the check lacks documentation, and was done 6 years ago.

> 




> It's documented in the comment you deleted:

> 

>   // In our regression testing, the Windows file system seems to

>   // have inconsistent modification times that sometimes

>   // erroneously trigger this error-handling path.

>    

> 

> We should confirm whether this is in fact still the case. Maybe this is caused by building on a networked file system, where a locally-changed file might have a different mtime locally and remotely (the local mtime may be precise where the remote one has been rounded to a multiple of 2 seconds by an underlying FAT filesystem)? If it's something like that, we could perhaps work around this by rounding the mtime to a multiple of 2 seconds ourselves.


I am not sure how to reproduce this build scenario, would you be able to provide some more stepped details?
I have tried emitting and including a PCH on a networked FAT32 drive, but no false warnings observed so far.

Are you asking for the 2 seconds tolerance to be part of this patch?
Or, as it seems the main problem here is the lack of a reproducible, are you ok with the idea of committing this patch first, to see if the inconsistent time stamps is still an issue?


http://reviews.llvm.org/D20867