2019-09-12 04:39:04 +08:00
|
|
|
// REQUIRES: shell
|
2019-09-12 05:19:27 +08:00
|
|
|
// REQUIRES: case-insensitive-filesystem
|
2019-09-12 04:39:04 +08:00
|
|
|
|
2018-06-22 05:45:24 +08:00
|
|
|
// RUN: rm -f %t.hmap
|
2019-09-12 04:39:04 +08:00
|
|
|
// RUN: sed -e "s:INPUTS_DIR:%S/Inputs:g" \
|
|
|
|
// RUN: %S/Inputs/nonportable-hmaps/foo.hmap.json > %t.hmap.json
|
|
|
|
// RUN: %hmaptool write %t.hmap.json %t.hmap
|
Preprocessor: Suppress -Wnonportable-include-path for header maps
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
2017-04-28 05:41:51 +08:00
|
|
|
// RUN: %clang_cc1 -Eonly \
|
2018-06-22 05:45:24 +08:00
|
|
|
// RUN: -I%t.hmap \
|
Preprocessor: Suppress -Wnonportable-include-path for header maps
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
2017-04-28 05:41:51 +08:00
|
|
|
// 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.
|
2019-09-12 04:39:04 +08:00
|
|
|
#include "Foo/Foo.h" // no warning
|
|
|
|
|
|
|
|
// Verify files with absolute paths in the header map are handled too.
|
|
|
|
// "Bar.h" is included twice to make sure that when we see potentially
|
|
|
|
// nonportable path, the file has been already discovered through a relative
|
|
|
|
// path which triggers the file to be opened and `FileEntry::RealPathName`
|
|
|
|
// to be set.
|
|
|
|
#include "Bar.h"
|
|
|
|
#include "Foo/Bar.h" // no warning
|
|
|
|
|
|
|
|
// But the presence of the absolute path in the header map is not enough. If we
|
|
|
|
// didn't use it to discover a file, shouldn't suppress the warning.
|
|
|
|
#include "headers/Foo/Baz.h" // expected-warning {{non-portable path}}
|