Finding headers in PCH with HeaderSearch

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

Finding headers in PCH with HeaderSearch

Axel Naumann
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.

_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev

ASTReader_HeaderSearch.diff (17K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Finding headers in PCH with HeaderSearch

Argyrios Kyrtzidis-2
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
> [hidden email]
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev

_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev

ast-resolve-paths.diff (14K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: 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
>> [hidden email]
>> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
>

_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev

ast-resolve-paths-v2.diff (15K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Finding headers in PCH with HeaderSearch

Argyrios Kyrtzidis-2
Cleaned it up, and commited in r125576.

On Feb 15, 2011, at 1:15 AM, Axel Naumann wrote:

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


_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev