This is an archive of the discontinued LLVM Phabricator instance.

[clang] Track how headers get included generally during lookup time
ClosedPublic

Authored by cishida on Apr 28 2022, 2:29 PM.

Details

Summary

tapi & clang-extractapi both attempt to construct then check against
how a header was included to determine api information when working
against multiple search paths, headermap, and vfsoverlay mechanisms.
Validating this against what the preprocessor sees during lookup time
makes this check more reliable.

Diff Detail

Event Timeline

cishida created this revision.Apr 28 2022, 2:29 PM
Herald added a project: Restricted Project. · View Herald TranscriptApr 28 2022, 2:29 PM
cishida requested review of this revision.Apr 28 2022, 2:29 PM
Herald added a project: Restricted Project. · View Herald TranscriptApr 28 2022, 2:29 PM
zixuw accepted this revision.Apr 28 2022, 2:38 PM

LGTM!

This revision is now accepted and ready to land.Apr 28 2022, 2:38 PM
jansvoboda11 requested changes to this revision.Apr 29 2022, 12:56 AM

Can you describe how come the check is not reliable without this patch? It might be worth fixing the underlying reason for the unreliability first.

clang/include/clang/Lex/HeaderSearch.h
121

I think HeaderFileInfo is supposed to be very small, hence the bit packing. Adding SmallString here might negatively impact performance. See https://reviews.llvm.org/D104344#inline-1039503

Note that HeaderFileInfo used to track aliases, but does not anymore: https://reviews.llvm.org/D123885

This revision now requires changes to proceed.Apr 29 2022, 12:56 AM
tschuett added inline comments.
clang/lib/Lex/HeaderSearch.cpp
1040

Why did the comment move?

cishida added a comment.EditedMay 2 2022, 11:57 AM

Can you describe how come the check is not reliable without this patch? It might be worth fixing the underlying reason for the unreliability first.

Different search paths alter where a header path may be resolved, in these cases we attempt to match the header based on how it was included <foo/bar.h>. We determine how the header was included by assembling from HeaderFileInfo::Framework and the filename associated with the FileEntry. This becomes inaccurate if a framework header is found without a header map and theres multiple locations to find it. This happens in an Xcode configuration when you have a Framework target, so theres potentially the same named headers in

  • DeviredData/.../foo.framework/Headers/bar.h
  • SDKROOT/foo.framework/Headers/bar.h
  • SRCROOT/foo/bar.h

and search paths for all of them (depending on order).
Given all the potential cases to cover, I think it would make sense to properly track what the include name was during lookup time as a reference-able source of truth.

Thank you for pointing out the potential performance cost. I could hold this information as apart of a container in HeaderSearch itself instead. This approach looks similar to HeaderSearch:: IncludeAliases which is only used for pragma include_alias.

cishida added inline comments.May 2 2022, 12:08 PM
clang/lib/Lex/HeaderSearch.cpp
1040

It refers to setting the DirInfo field, so I moved it to keep the comment near that assignment.

cishida updated this revision to Diff 426858.May 3 2022, 3:12 PM

Hold include name in HeaderSearch itself, keeping HeaderFileInfo lightweight.

cishida marked 2 inline comments as done.May 3 2022, 3:13 PM
jansvoboda11 accepted this revision.May 4 2022, 12:47 AM

LGTM, thanks!

This revision is now accepted and ready to land.May 4 2022, 12:47 AM