summaryrefslogtreecommitdiffstats
path: root/clang/test/Preprocessor/Inputs
Commit message (Collapse)AuthorAgeFilesLines
* Fix -Wnonportable-include-path suppression for header maps with absolute paths.Volodymyr Sapsai2019-09-113-1/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | In `DirectoryLookup::LookupFile` parameter `HasBeenMapped` doesn't cover the case when clang finds a file through a header map but doesn't remap the lookup filename because the target path is an absolute path. As a result, -Wnonportable-include-path suppression for header maps introduced in r301592 wasn't triggered. Change parameter `HasBeenMapped` to `IsInHeaderMap` and use parameter `MappedName` to track the filename remapping. This way we can handle both relative and absolute paths in header maps, and account for their specific properties, like filename remapping being a property preserved across lookups in multiple directories. rdar://problem/39516483 Reviewers: dexonsmith, bruno Reviewed By: dexonsmith Subscribers: jkorous, cfe-commits, ributzka Differential Revision: https://reviews.llvm.org/D58094 llvm-svn: 371655
* Don't diagnose errors when a file matches an include componentReid Kleckner2019-08-092-0/+1
| | | | | | | | | This regressed in r368322, and was reported as PR42948 and on the mailing list. The fix is to ignore the specific error code for this case. The problem doesn't seem to reproduce on Windows, where a different error code is used instead. llvm-svn: 368475
* [Preprocessor] Fix crash emitting note with framework location for "file not ↵Volodymyr Sapsai2019-05-271-0/+7
| | | | | | | | | | | | | | | | | | | | | | | | | found" error. A filename can be remapped with a header map to point to a framework header and we can find the corresponding framework without the header. But if the original filename doesn't have a remapped framework name, we'll fail to find its location and will dereference a null pointer during diagnostics emission. Fix by tracking remappings better and emit the note only if a framework is found before any of the remappings. rdar://problem/48883447 Reviewers: arphaman, erik.pilkington, jkorous Reviewed By: arphaman Subscribers: dexonsmith, cfe-commits Differential Revision: https://reviews.llvm.org/D61707 llvm-svn: 361779
* Reland "[Clang][PP] Add the __FILE_NAME__ builtin macro"Kristina Brooks2019-05-164-0/+9
| | | | | | | | | | | | | | | | | | | | | | | | | This relands commit rL360833 which caused issues on Win32 bots due to path handling/normalization differences. Now this uses `sys::path::filename` which should handle additional edge cases on Win32. Original commit: "[Clang][PP] Add the __FILE_NAME__ builtin macro" This patch adds the __FILE_NAME__ macro that expands to the last component of the path, similar to __FILE__ except with a guarantee that only the last path component (without the separator) will be rendered. I intend to follow through with discussion of this with WG14 as a potential inclusion in the C standard or failing that, try to discuss this with GCC developers since this extension is desired by GCC and Clang users/developers alike. Differential Revision: https://reviews.llvm.org/D61756 llvm-svn: 360938
* Revert r360833 until I can work out the issue with Win32 botsKristina Brooks2019-05-164-9/+0
| | | | | | | | | This reverts "r360833: [Clang][PP] Add the __FILE_NAME__ builtin macro." The tests are failing on Windows bots, reverting the patchset until I can work out why. llvm-svn: 360842
* [Clang][PP] Add the __FILE_NAME__ builtin macro.Kristina Brooks2019-05-164-0/+9
| | | | | | | | | | | | | | | | This patch adds the `__FILE_NAME__` macro that expands to the last component of the path, similar to `__FILE__` except with a guarantee that only the last path component (without the separator) will be rendered. I intend to follow through with discussion of this with WG14 as a potential inclusion in the C standard or failing that, try to discuss this with GCC developers since this extension is desired by GCC and Clang users/developers alike. Differential Revision: https://reviews.llvm.org/D61756 llvm-svn: 360833
* Improve the diagnostic for #include_next occurring in a file not foundRichard Smith2019-03-213-0/+3
| | | | | | | | | | | in the include path. Instead of making the incorrect claim that the included file has an absolute path, describe the actual problem: the including file was found either by absolute path, or relative to such a file, or relative to the primary source file. llvm-svn: 356712
* [Preprocessor] Stop entering included files after hitting a fatal error.Volodymyr Sapsai2018-07-253-0/+10
| | | | | | | | | | | | | | | | | 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
* Re-apply: Add python tool to dump and construct header mapsBruno Cardoso Lopes2018-06-216-0/+18
| | | | | | | | | | | | | | | | | | | | | | | | | 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
* Revert "Add python tool to dump and construct header maps"Bruno Cardoso Lopes2018-06-216-18/+0
| | | | | | | | | | | This reverts commit fcfa2dd517ec1a6045a81e8247e346d630a22618. Broke bots: http://lab.llvm.org:8011/builders/clang-x64-ninja-win7/builds/11315 http://lab.llvm.org:8011/builders/llvm-clang-x86_64-expensive-checks-win/builds/10411/steps/test-check-all/logs/stdio llvm-svn: 335196
* Add python tool to dump and construct header mapsBruno Cardoso Lopes2018-06-206-0/+18
| | | | | | | | | | | | | | | | | | | | | | | 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
* Preprocessor: Suppress -Wnonportable-include-path for header mapsDuncan P. N. Exon Smith2017-04-272-0/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Rename -Wmsvc-include to -Wmicrosoft-include, now that -Wmicrosoft is split up.Nico Weber2015-07-282-2/+2
| | | | | | | | | (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
* Fix what looks like accidentally repeated file contents. No behavior change.Nico Weber2015-07-282-6/+0
| | | | llvm-svn: 243376
* Force a header file input to the headermap test to have differentChandler Carruth2014-03-301-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | 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
* [HeaderSearch] Make sure we clear the mapped name from the ↵Argyrios Kyrtzidis2014-03-293-0/+2
| | | | | | | | LookupFileCacheInfo when we reset the start point. rdar://16462455 llvm-svn: 205071
* Add missing test file for r201615Reid Kleckner2014-02-181-0/+3
| | | | llvm-svn: 201617
* Fix false positives in -Wmsvc-include by continuing header searchReid Kleckner2014-02-181-1/+3
| | | | | | | | | | | 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
* Move test inputs into the Inputs directory (improvement/fix to r201419)David Blaikie2014-02-152-0/+2
| | | | llvm-svn: 201458
* Revert "Fix assertion failures on annot_* tokens in clang -E"Ben Langmuir2014-01-302-5/+0
| | | | | | | 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
* Fix assertion failures on annot_* tokens in clang -EBen Langmuir2014-01-302-0/+5
| | | | | | | In particular, #pragma clang __debug, and #include implicitly changed into @import were causing assertion failures. llvm-svn: 200475
* Move MS header search test inputs to Inputs/Reid Kleckner2013-12-275-0/+21
| | | | llvm-svn: 198086
* [Lex] Add support for 'user specified system frameworks' (see test case).Daniel Dunbar2012-04-053-0/+9
- 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
OpenPOWER on IntegriCloud