[cfe-dev] Finding headers in PCH with HeaderSearch

[Argyrios Kyrtzidis]

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.

-Argiris

-------------- next part --------------
A non-text attachment was scrubbed...
Name: ast-resolve-paths.diff
Type: application/octet-stream
Size: 14802 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20110207/d6d73e6d/attachment.obj>
-------------- next part --------------


On Feb 3, 2011, at 6:23 AM, Axel Naumann wrote:

> Hi,
> 
> 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
> name.
> 
> 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
> clang::ASTReader::ReadSLocEntry().
> 
> 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>_______________________________________________
> cfe-dev mailing list
> cfe-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev