[cfe-dev] Finding headers in PCH with HeaderSearch

[Axel Naumann]

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.

Argyrios Kyrtzidis wrote on 02/08/2011 12:54 AM:
> 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
> 
> 
> 
> 
> 
> 
> 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
> 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ast-resolve-paths-v2.diff
Type: text/x-patch
Size: 15610 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20110215/fd141479/attachment.bin>