This is an archive of the discontinued LLVM Phabricator instance.

-frewrite-includes: Fix support for __has_include_next
AbandonedPublic

Authored by davve on Mar 10 2017, 6:44 AM.

Details

Reviewers
bogner
rsmith
Summary

-frewrite-includes: Fix support for __has_include_next

__has_include_next handling inside -frewrite-includes had two
issues. First the Lookup parameter passed to HandleHasInclude was
unused and second, the Lookup paramenter pass was always nullptr and
thus never incremented as intended for __has_include_next
functionality to work.

-frewrite-includes works in two stages. The first stage runs the
preprocessor on the entire file and through callbacks records included
files. The second stage steps through the file again using the raw
lexer and replaces include directives with the recorded includes from
stage one. However in the second stage, the current directory lookup
is not maintained inside PP and PP.GetCurDirLookup() would always
return nullptr.

Instead of relying on PP.GetCurDirLookup(), use HeaderSearch to find
the lookup for the current file and move past it. Update the testsuite
to depend on the new behaviour instead of the old.

Fixes PR26828.

Diff Detail

Repository
rL LLVM

Event Timeline

davve created this revision.Mar 10 2017, 6:44 AM
davve edited the summary of this revision. (Show Details)Mar 10 2017, 6:47 AM
davve edited the summary of this revision. (Show Details)
davve edited the summary of this revision. (Show Details)Mar 10 2017, 6:52 AM
davve removed rL LLVM as the repository for this revision.Mar 10 2017, 8:29 AM
davve added a subscriber: cfe-commits.
davve abandoned this revision.Mar 20 2017, 9:49 AM

Eugene Velesevich noted in the bug that the patch is broken for multiple levels of headers:

Patch seems work only for first header with same name. I.e. code below finds first header even clang parses second or third ones. Thus __has_include_next is always true if there are two or more headers with same name.

Code below being the extra added LookupFile call.