summaryrefslogtreecommitdiffstats
path: root/clang/lib/Frontend/Rewrite/InclusionRewriter.cpp
Commit message (Collapse)AuthorAgeFilesLines
* 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