[PATCH] D124638: [clang] Track how headers get included generally during lookup time

[Cyndy Ishida via Phabricator via cfe-commits]

cishida added a comment.

In D124638#3481932 <https://reviews.llvm.org/D124638#3481932>, @jansvoboda11 wrote:

> 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 `include_alias`.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D124638/new/

https://reviews.llvm.org/D124638