forked from OSchip/llvm-project
cfc1f6a6ee
If a file search involves a header map, suppress
-Wnonportable-include-path. It's firing lots of false positives for
framework authors internally, and it's not trivial to fix.
Consider a framework called "Foo" with a main (installed) framework header
"Foo/Foo.h". It's atypical for "Foo.h" to actually live inside a
directory called "Foo" in the source repository. Instead, the
build system generates a header map while building the framework.
If Foo.h lives at the top-level of the source repository (common), and
the git repo is called ssh://some.url/foo.git, then the header map will
have something like:
Foo/Foo.h -> /Users/myname/code/foo/Foo.h
where "/Users/myname/code/foo" is the clone of ssh://some.url/foo.git.
After #import <Foo/Foo.h>, the current implementation of
-Wnonportable-include-path will falsely assume that Foo.h was found in a
nonportable way, because of the name of the git clone (.../foo/Foo.h).
However, that directory name was not involved in the header search at
all.
This commit adds an extra parameter to Preprocessor::LookupFile and
HeaderSearch::LookupFile to track if the search used a header map,
making it easy to suppress the warning. Longer term, once we find a way
to avoid the false positive, we should turn the warning back on.
rdar://problem/28863903
llvm-svn: 301592
|
||
|---|---|---|
| .. | ||
| TestFramework.framework | ||
| headermap-rel | ||
| headermap-rel2 | ||
| microsoft-header-search | ||
| nonportable-hmaps | ||