[cfe-dev] RFC: '--verify-pch /path/to/pch/file' to verify that a PCH file can be used

[Jean-Daniel Dupas]

Le 13 nov. 2013 à 07:00, Nico Weber <thakis at chromium.org> a écrit :

> On Tue, Nov 12, 2013 at 4:02 PM, Argyrios Kyrtzidis <kyrtzidis at apple.com> wrote:
> 
> On Nov 12, 2013, at 3:33 PM, Nico Weber <thakis at chromium.org> wrote:
> 
>> Wouldn't that mean that the build system had to launch clang for every pch file in noop builds?
> 
> Not necessarily, It would definitely have to launch it if there is going to be a clang invocation using the PCH file.
> 
>> And don't you want to force a full rebuild on compiler version changes anyhow?
>> 
> 
> Again, not necessarily, incremental version changes are not supposed to change the semantics of your code.
> 
> Sure, it's not 100% necessary, but it's a good idea and should always be done in practice (say, if you track performance over time, you don't want half of your .o files built with an older compiler and half with a newer), right?
> 
> I can think of two things causing a PCH file to be invalid:
> 
> 1. It's invalid due to one of its dependency inputs (the compiler binary that generated it, the .h files it includes) changing. Build systems rebuild files whose dependency inputs change, and the compiler probably always writes valid PCH files (if it doesn't, that's just a bug in the compiler, and if the compiler has such a bug, regenerating the PCH file again will probably just write an invalid PCH file again).
> 
> 2. It's invalid due to interaction with the translation unit it's included from. This probably can't happen (maybe the PCH uses some module include that's not compatible with some other module used by the translation unit?), but if it does it can't be diagnosed by a standalone diagnostic pass (since that doesn't check the PCH file in interaction with other PCH files).
> 
> Did I miss a scenario, or are you worried about scenario 1 and your build system just doesn't track all dependencies for PCH files?


Is there a build system that add the compiler binary as dependency for all compilers filed by default ?


> And the version is but one of multiple requirements for PCH verification.
> 
> 
>  
> 
>> 
>> On Tue, Nov 12, 2013 at 2:57 PM, Argyrios Kyrtzidis <kyrtzidis at apple.com> wrote:
>> Hi all,
>> 
>> Clang may reject using a PCH file for various reasons, e.g. because it was created from a different clang version, because an include file was modified, etc.
>> 
>> I propose that we add an option like '--verify-pch /path/to/pch/file' in clang that when invoked will:
>>   -Load the given PCH file
>>   -Verify it (check compiler version, stat includes, etc.)
>>   -Return 0 on success or non-zero and a diagnostic error on failure.
>> 
>> This can be used by a build system, if it so chooses, as part of its build dependencies calculation in order to verify that a PCH file is usable, and rebuild it if it is not.
>> Clang is the "ultimate authority" on what constitutes a usable PCH file, so it makes sense to delegate to it.
>> 
>> Apart from making the experience better when the PCH file becomes stale in ways the build system does not detect (e.g. due to different compiler version), another advantage of this approach is to allow us to reduce the amount of PCH verification that clang does by only doing it once at the beginning of the build process.
>> Some time ago we stopped stat'ing the system headers during PCH verification, since we considered it not worth the cost to stat them for every clang invocation. If the build system checked once at the beginning and then informed clang on subsequent invocations that it doesn't need to re-verify the PCH again, we could bring back verification of system headers.
>> 
>> Let me know what you think.
>> 
>> -Argyrios
>> _______________________________________________
>> cfe-dev mailing list
>> cfe-dev at cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
>> 
>> _______________________________________________
>> cfe-dev mailing list
>> cfe-dev at cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
> 
> 
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev

-- Jean-Daniel




-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20131113/7179c2ab/attachment.html>