To avoid excessive extra stat()s, only check the possible locations of
headers that weren't found at all (leading to a compile error).
For headers that *were* found, we don't check for files earlier on the
search path that could override them.
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
At first I thought this would be easy to test via clang/test/PCH, but the outer layers of PrecompiledPreamble seem to be totally distinct from PCHGenerator etc. This is only used in ASTUnit and clangd.
Maybe it's reachable in libclang but I couldn't easily work out how.
It is unfortunate that we are testing PrecompiledPreamble through clangd rather than its own unittest :/
clang/lib/Frontend/PrecompiledPreamble.cpp | ||
---|---|---|
101 | is there a common recovery logic implemented in clang that makes this logic worth it? I would rather check for File == nullptr in InclusionDirective and maybe put a fixme saying that this might still be set by a "recovering ppcallback". Up to you though. | |
137 | nit: braces | |
589 | i believe it can also be provided by an overridefile. maybe also check this above while going over RemappedFiles. i.e: for(... &R : ..RemappedFiles) { if(!stat(R.second)) return false; // A missing file has been remapped into an existing file. if(MissingFiles.count(R.first)) return false; .... } | |
590 | i am not sure if this works in all cases. Assume there's a mapped buffer for "a.h", which is relative to main file. I suppose this will be recorded with fullpath in MissingFiles, hence this lookup will fail. |
mostly LG, sorry for not noticing regularfile check(or maybe forgetting a discussion ...) at previous revision
clang/lib/Frontend/PrecompiledPreamble.cpp | ||
---|---|---|
108 | um, shouldn't this be if (File != nullptr) return; ? as we are only interested in not-found files? | |
529 | 128 seems to be more widely used :P | |
595 | what about others? at least symlinks ? |
clang/lib/Frontend/PrecompiledPreamble.cpp | ||
---|---|---|
108 | Yeah, I guess I should have run the tests :-) | |
595 | RealFileSystem::status() resolves symlinks (calls fs::status() with no resolve arg, defaults to true). That's the most important case, and other VFSes that support symlinks should really do the same for compatibility. |
is there a common recovery logic implemented in clang that makes this logic worth it?
because none of the existing clients seems to be implementing it.
I would rather check for File == nullptr in InclusionDirective and maybe put a fixme saying that this might still be set by a "recovering ppcallback".
Up to you though.