Fixes a problem when we have multiple inclusion cycles and try to
enumerate all possible ways to reach the max inclusion depth.
rdar://problem/38871876
Reviewers: bruno, rsmith, jkorous, aaron.ballman
Reviewed By: bruno, jkorous, aaron.ballman
Subscribers: dexonsmith, cfe-commits
Differential Revision: https://reviews.llvm.org/D48786
llvm-svn: 337953
Header maps are binary files used by Xcode, which are used to map
header names or paths to other locations. Clang has support for
those since its inception, but there's not a lot of header map
testing around.
Since it's a binary format, testing becomes pretty much brittle
and its hard to even know what's inside if you don't have the
appropriate tools.
Add a python based tool that allows creating and dumping header
maps based on a json description of those. While here, rewrite
tests to use the tool and remove the binary files from the tree.
This tool was initially written by Daniel Dunbar.
Thanks to Stella Stamenova for helping make this work on Windows.
Differential Revision: https://reviews.llvm.org/D46485
rdar://problem/39994722
llvm-svn: 335295
Header maps are binary files used by Xcode, which are used to map
header names or paths to other locations. Clang has support for
those since its inception, but there's not a lot of header map
testing around.
Since it's a binary format, testing becomes pretty much brittle
and its hard to even know what's inside if you don't have the
appropriate tools.
Add a python based tool that allows creating and dumping header
maps based on a json description of those. While here, rewrite
tests to use the tool and remove the binary files from the tree.
This tool was initially written by Daniel Dunbar.
Differential Revision: https://reviews.llvm.org/D46485
rdar://problem/39994722
llvm-svn: 335177
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
(Keep -Wmsvc-include around as an alias.)
While here, also replace the one other mention of "MSVC" in diagnostics with
"Microsoft", for consistency.
llvm-svn: 243444
contents than the header file by the same name under the system header
search root. Surprisingly, this is required to get the test to pass on
some systems.
So, it turns out that there exist filesystems in the world which unique
the inode of all files based on their contents. This results in two
files with the same contents at different paths suddenly having the same
inode. This doesn't actually cause any problems in practice as the
contents are the same, and the path used to access the files are the
same. However, it can cause tests like this one to be more brittle
because the file manager ends up de-duplicating the file entries by
inode. We don't have any other really easy ways to observe the behavior
shift because the whole point is that the #include written in the source
code doesn't contain the information -- instead it is contained in the
header map.
If folks have other solutions they would prefer, I'm more than happy to
work on them, but this seems a reasonable way to ensure that the test in
question exercises the code it wants to exercise.
llvm-svn: 205149
This makes Clang and LLVM -Wmsvc-include clean.
I believe the correct behavior here is to avoid updating the cache when
we find the header via MSVC's search rules.
Differential Revision: http://llvm-reviews.chandlerc.com/D2733
llvm-svn: 201615
This is causing a failure in the msan buildbot that I am having trouble
reproducing. Reverting until I can figure out what went wrong.
llvm-svn: 200492
- Developers of system frameworks need a way for their framework to be treated as a "system framework" during development. Otherwise, they are unable to properly test how their framework behaves when installed because of the semantic changes (in warning behavior) applied to system frameworks.
llvm-svn: 154105
