mikerice added a comment. In https://reviews.llvm.org/D46652#1101952, @kimgr wrote:
> > - Can you test what happens when you do `clang-cl.exe /Yc stdafx.h /Tp > stdafx.h`, i.e. compile the header directly as C++ code and generate .pch > from it? The normal MSVC modus operandi is to have stdafx.h included in all > source files (with /Yu) and stdafx.cpp to generate it (with /Yc). That > stdafx.cpp file serves no purpose, so I've played this trick to generate PCH > from the header directly. If it works, it might also be useful for your tests. It isn't always the case that the .cpp file serves no purpose. It's true that the MS project generators give you this setup but we've seen many projects over the years that use a regular source file with code in it to generate the PCH. The object file generated during PCH create can have real code and the compiler can take advantage of that fact by compiling less code in the compilation units that use the PCH (for example not instantiating some COMDAT data/functions that are know to be in the create object). This can speed up compilations significantly in some cases. I am not sure about your command: `clang-cl.exe /Yc stdafx.h /Tp stdafx.h`. The space makes this a compile with just /Yc (no through header). This patch doesn't address /Yc without the through header. Something like clang-cl /Yc /Tpstdafx.h would probably work if/when that is implemented. > - I think the current skip-warning is over-specific -- what if I put an > inline function before my PCH include? A global variable? A #pragma? Or am I > misunderstanding what skipping does? It seems to me that any non-comment > tokens before the PCH #include should raise a warning. Not any tokens. The through header "feature" compiles all the code in the file up to the through header. So normally you are used to seeing just comments and #include <stdafx.h>. That's one usage but your PCH can be created from a source like this: #include <header.h> #ifdef FOO #define FOO1 #endif #include <another.h> #include <stdafx.h> If the files using the PCH also have exactly this 'pch prefix' there is no problem and certainly no warning is expected. Some compilers also check that this 'prefix' matches and won't use a PCH if it doesn't match. The MS compiler does not do this but they do give a warning if a #define is seen that doesn't match the definition in the PCH (that may be new I hadn't noticed it before you mentioned it). It's a sign that the user is likely doing something wrong so a warning is probably warranted. We can do some simple checks here but I suppose the user is most interested in compilation speed when using a PCH. > - I find the "through header" terminology is a little hard to interpret, but > I did find it on MSDN, so maybe it's well established. Sorry about the terminology. I've been responsible for emulating this PCH mechanism for many years so I may be one of the few that understands it. I did try to keep that terminology out of the diagnostics but I don't really have a better name for through header. Thanks for taking a look at this. https://reviews.llvm.org/D46652 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
