summaryrefslogtreecommitdiffstats
path: root/clang/lib/Frontend/Rewrite/InclusionRewriter.cpp
Commit message (Collapse)AuthorAgeFilesLines
* make -frewrite-includes also rewrite conditions in #if/#elifLubos Lunak2019-09-181-120/+54
| | | | | | | | | | | | | | | Those conditions may use __has_include, which needs to be rewritten. The existing code has already tried to rewrite just __has_include, but it didn't work with macro expansion, so e.g. Qt's "#define QT_HAS_INCLUDE(x) __has_include(x)" didn't get handled properly. Since the preprocessor run knows what each condition evaluates to, just rewrite the entire condition. This of course requires that the -frewrite-include pass has the same setup as the following compilation, but that has always been the requirement. Differential Revision: https://reviews.llvm.org/D63508 llvm-svn: 372248
* Use FileEntryRef for PPCallbacks::FileSkippedAlex Lorenz2019-08-271-3/+3
| | | | | | | | This fixes the issue where a filename dependendency was missing if the file that was skipped was included through a symlink in an earlier run, if the file manager was reused between runs. llvm-svn: 369998
* Introduce FileEntryRef and use it when handling includes to report correct ↵Alex Lorenz2019-08-221-2/+2
| | | | | | | | | | | | | | | | | | | | | | | dependencies when the FileManager is reused across invocations This commit introduces a parallel API to FileManager's getFile: getFileEntryRef, which returns a reference to the FileEntry, and the name that was used to access the file. In the case of a VFS with 'use-external-names', the FileEntyRef contains the external name of the file, not the filename that was used to access it. The new API is adopted only in the HeaderSearch and Preprocessor for include file lookup, so that the accessed path can be propagated to SourceManager's FileInfo. SourceManager's FileInfo now can report this accessed path, using the new getName method. This API is then adopted in the dependency collector, which now correctly reports dependencies when a file is included both using a symlink and a real path in the case when the FileManager is reused across multiple Preprocessor invocations. Note that this patch does not fix all dependency collector issues, as the same problem is still present in other cases when dependencies are obtained using FileSkipped, InclusionDirective, and HasInclude. This will be fixed in follow-up commits. Differential Revision: https://reviews.llvm.org/D65907 llvm-svn: 369680
* [Preprocessor] Add a note with framework location for "file not found" error.Volodymyr Sapsai2019-02-051-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | When a framework with the same name is available at multiple framework search paths, we use the first matching location. If a framework at this location doesn't have all the headers, it can be confusing for developers because they see only an error `'Foo/Foo.h' file not found`, can find the complete framework with required header, and don't know the incomplete framework was used instead. Add a note explaining a framework without required header was found. Also mention framework directory path to make it easier to find the incomplete framework. rdar://problem/39246514 Reviewers: arphaman, erik.pilkington, jkorous Reviewed By: jkorous Subscribers: jkorous, dexonsmith, cfe-commits Differential Revision: https://reviews.llvm.org/D56561 llvm-svn: 353231
* Update the file headers across all of the LLVM projects in the monorepoChandler Carruth2019-01-191-4/+3
| | | | | | | | | | | | | | | | | to reflect the new license. We understand that people may be surprised that we're moving the header entirely to discuss the new license. We checked this carefully with the Foundation's lawyer and we believe this is the correct approach. Essentially, all code in the project is now made available by the LLVM project under our new license, so you will see that the license headers include that license only. Some of our contributors have contributed code under our old license, and accordingly, we have retained a copy of our old license notice in the top-level files in each project and repository. llvm-svn: 351636
* Fix clang -Wimplicit-fallthrough warnings across llvm, NFCReid Kleckner2018-11-011-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | This patch should not introduce any behavior changes. It consists of mostly one of two changes: 1. Replacing fall through comments with the LLVM_FALLTHROUGH macro 2. Inserting 'break' before falling through into a case block consisting of only 'break'. We were already using this warning with GCC, but its warning behaves slightly differently. In this patch, the following differences are relevant: 1. GCC recognizes comments that say "fall through" as annotations, clang doesn't 2. GCC doesn't warn on "case N: foo(); default: break;", clang does 3. GCC doesn't warn when the case contains a switch, but falls through the outer case. I will enable the warning separately in a follow-up patch so that it can be cleanly reverted if necessary. Reviewers: alexfh, rsmith, lattner, rtrieu, EricWF, bollu Differential Revision: https://reviews.llvm.org/D53950 llvm-svn: 345882
* Reland '[clang] Adding CharacteristicKind to PPCallbacks::InclusionDirective'Julie Hockett2018-05-101-2/+4
| | | | | | | | | | | | | | This commit relands r331904. Adding a SrcMgr::CharacteristicKind parameter to the InclusionDirective in PPCallbacks, and updating calls to that function. This will be useful in https://reviews.llvm.org/D43778 to determine which includes are system headers. Differential Revision: https://reviews.llvm.org/D46614 llvm-svn: 332021
* Revert "[clang] Adding CharacteristicKind to PPCallbacks::InclusionDirective"Julie Hockett2018-05-091-4/+2
| | | | | | This reverts commit r331904 because of a memory leak. llvm-svn: 331932
* [clang] Adding CharacteristicKind to PPCallbacks::InclusionDirectiveJulie Hockett2018-05-091-2/+4
| | | | | | | | | | | Adding a SrcMgr::CharacteristicKind parameter to the InclusionDirective in PPCallbacks, and updating calls to that function. This will be useful in https://reviews.llvm.org/D43778 to determine which includes are system headers. Differential Revision: https://reviews.llvm.org/D46614 llvm-svn: 331904
* Fix evaluation of `__has_include_next` during -frewrite-includes.Volodymyr Sapsai2018-04-131-14/+18
| | | | | | | | | | | | | | | | | | | | | | | `__has_include_next` requires correct DirectoryLookup for being evaluated correctly. We were using Preprocessor::GetCurDirLookup() but we were calling it after the preprocessor finished its work. And in this case CurDirLookup is always nullptr which makes `__has_include_next` behave as `__has_include`. Fix by storing and using CurDirLookup when preprocessor enters a file, not when we rewrite the includes. rdar://problem/36305026 Reviewers: bkramer Reviewed By: bkramer Subscribers: jkorous-apple, cfe-commits Differential Revision: https://reviews.llvm.org/D45603 llvm-svn: 330041
* Support non-identifier module names when preprocessing modules.Richard Smith2017-06-191-5/+5
| | | | llvm-svn: 305758
* PR32848: There isn't necessarily a FileChanged or FileSkipped for every ↵Richard Smith2017-06-021-4/+3
| | | | | | | | | InclusionDirective callback. In particular, you don't get one if the inclusion directive encountered an error. Don't assert in that case. llvm-svn: 304506
* Add #pragma clang module begin/end pragmas and generate them when ↵Richard Smith2017-05-041-0/+30
| | | | | | | | | | | | | | preprocessing a module. These pragmas are intended to simulate the effect of entering or leaving a file with an associated module. This is not completely implemented yet: declarations between the pragmas will not be attributed to the correct module, but macro visibility is already functional. Modules named by #pragma clang module begin must already be known to clang (in some module map that's either loaded or on the search path). llvm-svn: 302098
* PR26771: don't forget the " 2" (returning from #included file) linemarker ↵Richard Smith2017-04-291-14/+9
| | | | | | after including an empty file with -frewrite-includes. llvm-svn: 301727
* Add pragma to perform module import and use it in -E output.Richard Smith2017-04-291-4/+2
| | | | | | | | | | | | | | | | | | | | | Many of our supported configurations support modules but do not have any first-class syntax to perform a module import. This leaves us with a problem: there is no way to represent the expansion of a #include that imports a module in the -E output for such languages. (We don't want to just leave it as a #include because that requires the consumer of the preprocessed source to have the same file system layout and include paths as the creator.) This patch adds a new pragma: #pragma clang module import MODULE.NAME.HERE that imports a module, and changes -E and -frewrite-includes to use it when rewriting a #include that maps to a module import. We don't make any attempt to use a native language syntax import if one exists, to get more consistent output. (If in the future, @import and #include have different semantics in some way, the pragma will track the #include semantics.) llvm-svn: 301725
* Preprocessor: Suppress -Wnonportable-include-path for header mapsDuncan P. N. Exon Smith2017-04-271-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Use StringRef for MemoryBuffer identifier API (NFC)Mehdi Amini2016-10-011-3/+3
| | | | llvm-svn: 283043
* [modules] Don't write @import in -E output if the current language mode doesn'tRichard Smith2016-04-081-1/+3
| | | | | | support @import; use the form as written instead. llvm-svn: 265756
* Refactor module lookup when looking up a header file, and wire through the ↵Richard Smith2015-10-161-1/+2
| | | | | | requesting module. No functionality change. llvm-svn: 250554
* Replace double-negated !SourceLocation.isInvalid() with ↵Yaron Keren2015-10-031-1/+1
| | | | | | SourceLocation.isValid(). llvm-svn: 249228
* Fix a couple of unused variables in no-assertsJustin Bogner2015-07-011-0/+2
| | | | llvm-svn: 241144
* -frewrite-includes: Prefer insert to emplaceJustin Bogner2015-07-011-3/+4
| | | | | | Some bots didn't like r241140. llvm-svn: 241141
* -frewrite-includes: Rework how includes and modules are differentiatedJustin Bogner2015-07-011-39/+50
| | | | | | | | | | | | | | | | | | | | The map of FileChange structs here was storing two disjoint types of information: 1. A pointer to the Module that an #include directive implicitly imported 2. A FileID and FileType for an included file. These would be left uninitialized in the Module case. This change splits these two kinds of information into their own maps, which both simplifies how we access either and avoids the undefined behaviour we were hitting due to the uninitialized fields in the included file case. Mostly NFC, but fixes some errors found by self-host with ubsan. llvm-svn: 241140
* Fix misleading parameter name for PPCallbacks::FileSkipped.Nikola Smiljanic2015-05-121-2/+2
| | | | | | Patch thanks to Vladimir Voskresensky. llvm-svn: 237115
* Fix a [-Werror,-Wreorder] initialization ordering error.Eric Christopher2015-02-261-2/+2
| | | | llvm-svn: 230589
* Add -fuse-line-directive flag to control usage of #line with -EReid Kleckner2015-02-261-10/+10
| | | | | | | | | | | | | | | | | | Currently -fms-extensions controls this behavior, which doesn't make much sense. It means we can't identify what is and isn't a system header when compiling our own preprocessed output, because #line doesn't represent this information. If someone is feeding Clang's preprocessed output to another compiler, they can use this flag. Fixes PR20553. Reviewers: rsmith Differential Revision: http://reviews.llvm.org/D5217 llvm-svn: 230587
* Unique_ptrify PPCallbacks ownership.Craig Topper2014-09-101-1/+1
| | | | | | Unique_ptr creation stil needs to be moved earlier at some of the call sites. llvm-svn: 217474
* -frewrite-includes: Normalize line endings to match the main source fileReid Kleckner2014-09-051-52/+90
| | | | | | | | | | | | | | | | | | | | | | It is very common to include headers with DOS-style line endings, such as windows.h, from source files with Unix-style line endings. Previously, we would end up with mixed line endings and #endifs that appeared to be on the same line: #if 0 /* expanded by -frewrite-includes */ #include <windows.h>^M#endif /* expanded by -frewrite-includes */ Clang treats either of \r or \n as a line ending character, so this is purely a cosmetic issue. This has no automated test because most Unix tools on Windows will implictly convert CRLF to LF when reading files, making it very hard to detect line ending mismatches. FileCheck doesn't understand {{\r}} either. Fixes PR20552. llvm-svn: 217259
* Correctly implement -include search logic.Manuel Klimek2014-08-121-3/+6
| | | | | | | | | | | | | | | According to the gcc docs, -include uses the current working directory for the lookup instead of the main source file. This patch gets rid of NormalizeIncludePath (which relied on an implementation detail of FileManager / FileEntry for the include path logic to work), and instead hands the correct lookup information down to LookupFile. This will allow us to change the FileEntry's behavior regarding its Name caching. llvm-svn: 215433
* Make clang's rewrite engine a core featureAlp Toker2014-07-161-0/+547
The rewrite facility's footprint is small so it's not worth going to these lengths to support disabling at configure time, particularly since key compiler features now depend on it. Meanwhile the Objective-C rewriters have been moved under the ENABLE_CLANG_ARCMT umbrella for now as they're comparatively heavy and still potentially worth excluding from lightweight builds. Tests are now passing with any combination of feature flags. The flags historically haven't been tested by LLVM's build servers so caveat emptor. llvm-svn: 213171
OpenPOWER on IntegriCloud