Finding headers in PCH with HeaderSearch


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 :slight_smile:

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
clang::SourceManager::getFileIDSlow() into

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
included file).

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?

Cheers, Axel.

ASTReader_HeaderSearch.diff (17.6 KB)

Hi Axel, sorry for the delay.

Unless I'm misunderstanding something you basically would like to be able to move headers+PCH file around but the header files will always be relative to the PCH the same way, right ?
Couldn't we just store in PCH the directory in which the PCH file was originally created and use that to try to resolve the header files relative to that ?

I attached a quick hack that does that for illustration, let me know if it is suitable for your use cases.


ast-resolve-paths.diff (14.5 KB)

Hi Argyrios,

works like a charm (for our use case :-)! I have adapted your patch to
the current trunk and added a test.

Can you commit it?

Cheers, Axel.

ast-resolve-paths-v2.diff (15.2 KB)

Cleaned it up, and commited in r125576.