As promised before, attached patch finds the original headers of PCHs
even if they are at a different full path than the original ones, by
invoking HeaderSearch. For that, the ASTReader obviously needs to know
how the header was included ("a.h" vs. "../sub/a.h"), information that
is not available in the PCH right now, and that is difficult to extract
on the ASTReader side (do we have the memory buffer for the include
location?) but easily accessible at the ASTWriter side. So I added it to
the SLOC_FILE blob, behind the terminating \0 of the header's full path.
That is ugly, but wait, it gets worse
Because of the header search being include-location dependent (#include
"b.h" means something else from sub/a.h than from ./a.h) I also need to
access the "current directory", as defined by the main file. This in
turn means that the ASTReader now needs to be informed of the main file
I needed to get the include location's FileEntry which defines the
directory to use for header search. I didn't manage to use the
IncludeLocation part of the AST: converting that to the FileID with
SourceManager::getFileID() triggers an infinite recursion through
Instead I decided to extend the PCH to store the FileID as an unsigned,
which in turn allows me to retrieve the FileEntry directly through the
SLocs (I assume that the including file is always in front of the
And I threw in a test that shows diagnostics with source code from the
moved headers. Clang's tests remain happy.
Could I have your comments, please?
ASTReader_HeaderSearch.diff (17.6 KB)