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 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
