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
17 lines
606 B
C
17 lines
606 B
C
// RUN: %clang_cc1 -Eonly \
|
|
// RUN: -I%S/Inputs/nonportable-hmaps/foo.hmap \
|
|
// RUN: -I%S/Inputs/nonportable-hmaps \
|
|
// RUN: %s -verify
|
|
//
|
|
// foo.hmap contains: Foo/Foo.h -> headers/foo/Foo.h
|
|
//
|
|
// Header search of "Foo/Foo.h" follows this path:
|
|
// 1. Look for "Foo/Foo.h".
|
|
// 2. Find "Foo/Foo.h" in "nonportable-hmaps/foo.hmap".
|
|
// 3. Look for "headers/foo/Foo.h".
|
|
// 4. Find "headers/foo/Foo.h" in "nonportable-hmaps".
|
|
// 5. Return.
|
|
//
|
|
// There is nothing nonportable; -Wnonportable-include-path should not fire.
|
|
#include "Foo/Foo.h" // expected-no-diagnostics
|