summaryrefslogtreecommitdiffstats
path: root/clang/lib/Lex/HeaderSearch.cpp
Commit message (Collapse)AuthorAgeFilesLines
* Remove trailing spaceFangrui Song2018-07-301-16/+16
| | | | | | sed -Ei 's/[[:space:]]+$//' include/**/*.{def,h,td} lib/**/*.{cpp,h} llvm-svn: 338291
* Reapply r336660: [Modules] Autoload subdirectory modulemaps with specific ↵Bruno Cardoso Lopes2018-07-181-7/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | LangOpts Summary: Reproducer and errors: https://bugs.llvm.org/show_bug.cgi?id=37878 lookupModule was falling back to loadSubdirectoryModuleMaps when it couldn't find ModuleName in (proper) search paths. This was causing iteration over all files in the search path subdirectories for example "/usr/include/foobar" in bugzilla case. Users don't expect Clang to load modulemaps in subdirectories implicitly, and also the disk access is not cheap. if (AllowExtraModuleMapSearch) true with ObjC with @import ModuleName. Reviewers: rsmith, aprantl, bruno Subscribers: cfe-commits, teemperor, v.g.vassilev Differential Revision: https://reviews.llvm.org/D48367 llvm-svn: 337430
* Revert "[modules] Fix 37878; Autoload subdirectory modulemaps with specific ↵Bruno Cardoso Lopes2018-07-121-10/+7
| | | | | | | | | | | | | | | LangOpts" This reverts commit f40124d4f05ecf4f880cf4e8f26922d861f705f3 / r336660. This change shouldn't be affecting `@import` behavior, but turns out it is: https://ci.swift.org/view/swift-master-next/job/oss-swift-incremental-RA-osx-master-next/2800/consoleFull#-12570166563122a513-f36a-4c87-8ed7-cbc36a1ec144 Working on a reduced testcase for this, reverting in the meantime. rdar://problem/42102222 llvm-svn: 336920
* [modules] Fix 37878; Autoload subdirectory modulemaps with specific LangOptsYuka Takahashi2018-07-101-7/+10
| | | | | | | | | | | | | | | | | | | | | | | | Summary: Reproducer and errors: https://bugs.llvm.org/show_bug.cgi?id=37878 lookupModule was falling back to loadSubdirectoryModuleMaps when it couldn't find ModuleName in (proper) search paths. This was causing iteration over all files in the search path subdirectories for example "/usr/include/foobar" in bugzilla case. Users don't expect Clang to load modulemaps in subdirectories implicitly, and also the disk access is not cheap. if (AllowExtraModuleMapSearch) true with ObjC with @import ModuleName. Reviewers: rsmith, aprantl, bruno Subscribers: cfe-commits, teemperor, v.g.vassilev Differential Revision: https://reviews.llvm.org/D48367 llvm-svn: 336660
* Warning for framework include violation from Headers to PrivateHeadersBruno Cardoso Lopes2018-06-251-5/+20
| | | | | | | | | | | | | | | | | | | | | | | | | | Framework vendors usually layout their framework headers in the following way: Foo.framework/Headers -> "public" headers Foo.framework/PrivateHeader -> "private" headers Since both headers in both directories can be found with #import <Foo/some-header.h>, it's easy to make mistakes and include headers in Foo.framework/PrivateHeader from headers in Foo.framework/Headers, which usually configures a layering violation on Darwin ecosystems. One of the problem this causes is dep cycles when modules are used, since it's very common for "private" modules to include from the "public" ones; adding an edge the other way around will trigger cycles. Add a warning to catch those cases such that: ./A.framework/Headers/A.h:1:10: warning: public framework header includes private framework header 'A/APriv.h' #include <A/APriv.h> ^ rdar://problem/38712182 llvm-svn: 335542
* Re-apply: Warning for framework headers using double quote includesBruno Cardoso Lopes2018-06-221-1/+64
| | | | | | | | | | | | | | | | | | | | | | | | | | | Introduce -Wquoted-include-in-framework-header, which should fire a warning whenever a quote include appears in a framework header and suggest a fix-it. For instance, for header A.h added in the tests, this is how the warning looks like: ./A.framework/Headers/A.h:2:10: warning: double-quoted include "A0.h" in framework header, expected angle-bracketed instead [-Wquoted-include-in-framework-header] #include "A0.h" ^~~~~~ <A/A0.h> ./A.framework/Headers/A.h:3:10: warning: double-quoted include "B.h" in framework header, expected angle-bracketed instead [-Wquoted-include-in-framework-header] #include "B.h" ^~~~~ <B.h> This helps users to prevent frameworks from using local headers when in fact they should be targetting system level ones. The warning is off by default. Differential Revision: https://reviews.llvm.org/D47157 rdar://problem/37077034 llvm-svn: 335375
* Revert "Warning for framework headers using double quote includes"Bruno Cardoso Lopes2018-06-211-64/+1
| | | | | | | | | | | This reverts commit 9b5ff2db7e31c4bb11a7d468260b068b41c7c285. 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: 335195
* Warning for framework headers using double quote includesBruno Cardoso Lopes2018-06-201-1/+64
| | | | | | | | | | | | | | | | | | | | | | | | | | | Introduce -Wquoted-include-in-framework-header, which should fire a warning whenever a quote include appears in a framework header and suggest a fix-it. For instance, for header A.h added in the tests, this is how the warning looks like: ./A.framework/Headers/A.h:2:10: warning: double-quoted include "A0.h" in framework header, expected angle-bracketed instead [-Wquoted-include-in-framework-header] #include "A0.h" ^~~~~~ <A/A0.h> ./A.framework/Headers/A.h:3:10: warning: double-quoted include "B.h" in framework header, expected angle-bracketed instead [-Wquoted-include-in-framework-header] #include "B.h" ^~~~~ <B.h> This helps users to prevent frameworks from using local headers when in fact they should be targetting system level ones. The warning is off by default. Differential Revision: https://reviews.llvm.org/D47157 rdar://problem/37077034 llvm-svn: 335184
* Remove \brief commands from doxygen comments.Adrian Prantl2018-05-091-4/+4
| | | | | | | | | | | | | | | | | | | This is similar to the LLVM change https://reviews.llvm.org/D46290. We've been running doxygen with the autobrief option for a couple of years now. This makes the \brief markers into our comments redundant. Since they are a visual distraction and we don't want to encourage more \brief markers in new code either, this patch removes them all. Patch produced by for i in $(git grep -l '\@brief'); do perl -pi -e 's/\@brief //g' $i & done for i in $(git grep -l '\\brief'); do perl -pi -e 's/\\brief //g' $i & done Differential Revision: https://reviews.llvm.org/D46320 llvm-svn: 331834
* Revert r329684 (and follow-ups 329693, 329714). See discussion on ↵Nico Weber2018-04-101-26/+0
| | | | | | https://reviews.llvm.org/D43578. llvm-svn: 329739
* -ftime-report switch support in Clang.Andrew V. Tischenko2018-04-101-0/+26
| | | | | | | | | | The current support of the feature produces only 2 lines in report: -Some general Code Generation Time; -Total time of Backend Consumer actions. This patch extends Clang time report with new lines related to Preprocessor, Include Filea Search, Parsing, etc. Differential Revision: https://reviews.llvm.org/D43578 llvm-svn: 329684
* Fix typos in clangAlexander Kornienko2018-04-061-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Found via codespell -q 3 -I ../clang-whitelist.txt Where whitelist consists of: archtype cas classs checkk compres definit frome iff inteval ith lod methode nd optin ot pres statics te thru Patch by luzpaz! (This is a subset of D44188 that applies cleanly with a few files that have dubious fixes reverted.) Differential revision: https://reviews.llvm.org/D44188 llvm-svn: 329399
* [Lexer] Support adding working directory to relative search dir for #include ↵Eric Liu2018-01-291-11/+22
| | | | | | | | | | | | shortening in HeaderSearch. Reviewers: bkramer Subscribers: mgorny, hintonda, cfe-commits Differential Revision: https://reviews.llvm.org/D42577 llvm-svn: 323647
* Track shadow modules with a generation counter.Bruno Cardoso Lopes2018-01-051-11/+9
| | | | | | | | | | This is a follow up to r321855, closing the gap between our internal shadow modules implementation and upstream. It has been tested for longer and provides a better approach for tracking shadow modules. Mostly NFCI. rdar://problem/23612102 llvm-svn: 321906
* Reapply r321781: [Modules] Allow modules specified by -fmodule-map-file to ↵Bruno Cardoso Lopes2018-01-051-9/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | shadow implicitly found ones When modules come from module map files explicitly specified by -fmodule-map-file= arguments, allow those to override/shadow modules with the same name that are found implicitly by header search. If such a module is looked up by name (e.g. @import), we will always find the one from -fmodule-map-file. If we try to use a shadowed module by including one of its headers report an error. This enables developers to force use of a specific copy of their module to be used if there are multiple copies that would otherwise be visible, for example if they develop modules that are installed in the default search paths. Patch originally by Ben Langmuir, http://lists.llvm.org/pipermail/cfe-commits/Week-of-Mon-20151116/143425.html Based on cfe-dev discussion: http://lists.llvm.org/pipermail/cfe-dev/2015-November/046164.html Differential Revision: https://reviews.llvm.org/D31269 rdar://problem/23612102 llvm-svn: 321855
* Revert "[Modules] Allow modules specified by -fmodule-map-file to shadow ↵Bruno Cardoso Lopes2018-01-041-11/+9
| | | | | | | | | | | implicitly found ones" This reverts r321781 until I fix the leaks pointed out by bots: http://lab.llvm.org:8011/builders/sanitizer-x86_64-linux-fast/builds/12146 http://lab.llvm.org:8011/builders/sanitizer-x86_64-linux-bootstrap/builds/3741 llvm-svn: 321786
* [Modules] Allow modules specified by -fmodule-map-file to shadow implicitly ↵Bruno Cardoso Lopes2018-01-041-9/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | found ones When modules come from module map files explicitly specified by -fmodule-map-file= arguments, allow those to override/shadow modules with the same name that are found implicitly by header search. If such a module is looked up by name (e.g. @import), we will always find the one from -fmodule-map-file. If we try to use a shadowed module by including one of its headers report an error. This enables developers to force use of a specific copy of their module to be used if there are multiple copies that would otherwise be visible, for example if they develop modules that are installed in the default search paths. Patch originally by Ben Langmuir, http://lists.llvm.org/pipermail/cfe-commits/Week-of-Mon-20151116/143425.html Based on cfe-dev discussion: http://lists.llvm.org/pipermail/cfe-dev/2015-November/046164.html Differential Revision: https://reviews.llvm.org/D31269 rdar://problem/23612102 llvm-svn: 321781
* [Modules] Change private modules rules and warningsBruno Cardoso Lopes2017-12-221-5/+8
| | | | | | | | | | | | | | | | We used to advertise private modules to be declared as submodules (Foo.Private). This has proven to not scale well since private headers might carry several dependencies, introducing unwanted content into the main module and often causing dep cycles. Change the canonical way to name it to Foo_Private, forcing private modules as top level ones, and provide warnings under -Wprivate-module to suggest fixes for other private naming. Update documentation to reflect that. rdar://problem/31173501 llvm-svn: 321337
* [Lex] Fix some Clang-tidy modernize and Include What You Use warnings; other ↵Eugene Zelenko2017-12-061-34/+32
| | | | | | minor fixes (NFC). llvm-svn: 319986
* [modules] Add ability to specify module name to module file mapping (reapply)Boris Kolpackov2017-08-311-9/+14
| | | | | | | | | | | | | | | | | | | | Extend the -fmodule-file option to support the [<name>=]<file> value format. If the name is omitted, then the old semantics is preserved (the module file is loaded whether needed or not). If the name is specified, then the mapping is treated as just another prebuilt module search mechanism, similar to -fprebuilt-module-path, and the module file is only loaded if actually used (e.g., via import). With one exception: this mapping also overrides module file references embedded in other modules (which can be useful if module files are moved/renamed as often happens during remote compilation). This override semantics requires some extra work: we now store the module name in addition to the file name in the serialized AST representation. Reviewed By: rsmith Differential Revision: https://reviews.llvm.org/D35020 llvm-svn: 312220
* Revert r312105 [modules] Add ability to specify module name to module file ↵Victor Leschuk2017-08-301-14/+9
| | | | | | | | mapping Looks like it breaks win10 builder. llvm-svn: 312112
* [modules] Add ability to specify module name to module file mappingBoris Kolpackov2017-08-301-9/+14
| | | | | | | | | | | | | | | | | | | | Extend the -fmodule-file option to support the [<name>=]<file> value format. If the name is omitted, then the old semantics is preserved (the module file is loaded whether needed or not). If the name is specified, then the mapping is treated as just another prebuilt module search mechanism, similar to -fprebuilt-module-path, and the module file is only loaded if actually used (e.g., via import). With one exception: this mapping also overrides module file references embedded in other modules (which can be useful if module files are moved/renamed as often happens during remote compilation). This override semantics requires some extra work: we now store the module name in addition to the file name in the serialized AST representation. Reviewed By: rsmith Differential Revision: https://reviews.llvm.org/D35020 llvm-svn: 312105
* Revert "[Modules] Prevent #import to reenter header if not building a module."Bruno Cardoso Lopes2017-08-121-1/+1
| | | | | | | This reverts commit r310605. Richard pointed out a better way to achieve this, which I'll post a patch for soon. llvm-svn: 310775
* [Modules] Prevent #import to reenter header if not building a module.Bruno Cardoso Lopes2017-08-101-1/+1
| | | | | | | | | | When non-modular headers are imported while not building a module but in -fmodules mode, be conservative and preserve the default #import semantic: do not reenter headers. rdar://problem/33745031 llvm-svn: 310605
* Support lazy stat'ing of files referenced by module maps.Richard Smith2017-06-021-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch adds support for a `header` declaration in a module map to specify certain `stat` information (currently, size and mtime) about that header file. This has two purposes: - It removes the need to eagerly `stat` every file referenced by a module map. Instead, we track a list of unresolved header files with each size / mtime (actually, for simplicity, we track submodules with such headers), and when attempting to look up a header file based on a `FileEntry`, we check if there are any unresolved header directives with that `FileEntry`'s size / mtime and perform deferred `stat`s if so. - It permits a preprocessed module to be compiled without the original files being present on disk. The only reason we used to need those files was to get the `stat` information in order to do header -> module lookups when using the module. If we're provided with the `stat` information in the preprocessed module, we can avoid requiring the files to exist. Unlike most `header` directives, if a `header` directive with `stat` information has no corresponding on-disk file the enclosing module is *not* marked unavailable (so that behavior is consistent regardless of whether we've resolved a header directive, and so that preprocessed modules don't get marked unavailable). We could actually do this for all `header` directives: the only reason we mark the module unavailable if headers are missing is to give a diagnostic slightly earlier (rather than waiting until we actually try to build the module / load and validate its .pcm file). Differential Revision: https://reviews.llvm.org/D33703 llvm-svn: 304515
* [modules] When compiling a preprocessed module map, look for headers relativeRichard Smith2017-05-311-2/+15
| | | | | | | | | | | | to the original module map. Also use the path and name of the original module map when emitting that information into the .pcm file. The upshot of this is that the produced .pcm file will track information for headers in their original locations (where the module was preprocessed), not relative to whatever directory the preprocessed module map was in when it was built. llvm-svn: 304346
* Add support for building modules from preprocessed source.Richard Smith2017-05-051-4/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | To support this, an optional marker "#pragma clang module contents" is recognized in module map files, and the rest of the module map file from that point onwards is treated as the source of the module. Preprocessing a module map produces the input module followed by the marker and then the preprocessed contents of the module. Ignoring line markers, a preprocessed module might look like this: module A { header "a.h" } #pragma clang module contents #pragma clang module begin A // ... a.h ... #pragma clang module end The preprocessed output generates line markers, which are not accepted by the module map parser, so -x c++-module-map-cpp-output should be used to compile such outputs. A couple of major parts do not work yet: 1) The files that are listed in the module map must exist on disk, in order to build the on-disk header -> module lookup table in the PCM file. To fix this, we need the preprocessed output to track the file size and other stat information we might use to build the lookup table. 2) Declaration ownership semantics don't work properly yet, since mapping from a source location to a module relies on mapping from FileIDs to modules, which we can't do if module transitions can occur in the middle of a file. llvm-svn: 302309
* Preprocessor: Suppress -Wnonportable-include-path for header mapsDuncan P. N. Exon Smith2017-04-271-3/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Fix handling of -fmodule-map-file=X where X has no directory component.Richard Smith2017-03-091-2/+4
| | | | llvm-svn: 297349
* [Modules] Support #import when entering files with modulesBruno Cardoso Lopes2017-01-111-4/+43
| | | | | | | | | | | | Textual headers and builtins that are #import'd from different modules should get re-entered when these modules are independent from each other. Differential Revision: https://reviews.llvm.org/D26267 rdar://problem/25881934 llvm-svn: 291644
* shared_ptrify (from InclusiveRefCntPtr) HeaderSearchOptionsDavid Blaikie2017-01-061-1/+1
| | | | llvm-svn: 291202
* [modules] Handle modules with nonstandard names in module.private.modulemapsGraydon Hoare2016-12-211-4/+24
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: The module system supports accompanying a primary module (say Foo) with an auxiliary "private" module (defined in an adjacent module.private.modulemap file) that augments the primary module when associated private headers are available. The feature is intended to be used to augment the primary module with a submodule (say Foo.Private), however some users in the wild are choosing to augment the primary module with an additional top-level module with a "similar" name (in all cases so far: FooPrivate). This "works" when a user of the module initially imports a private header, such as '#import "Foo/something_private.h"' since the Foo import winds up importing FooPrivate in passing. But if the import is subsequently recorded in a PCH file, reloading the PCH will fail to validate because of a cross-check that attempts to find the module.modulemap (or module.private.modulemap) using HeaderSearch algorithm, applied to the "FooPrivate" name. Since it's stored in Foo.framework/Modules, not FooPrivate.framework/Modules, the check fails and the PCH is rejected. This patch adds a compensatory workaround in the HeaderSearch algorithm when searching (and failing to find) a module of the form FooPrivate: the name used to derive filesystem paths is decoupled from the module name being searched for, and if the initial search fails and the module is named "FooPrivate", the filesystem search name is altered to remove the "Private" suffix, and the algorithm is run a second time (still looking for a module named FooPrivate, but looking in directories derived from Foo). Accompanying this change is a new warning that triggers when a user loads a module.private.modulemap that defines a top-level module with a different name from the top-level module defined in its adjacent module.modulemap. Reviewers: doug.gregor, manmanren, bruno Subscribers: bruno, cfe-commits Differential Revision: https://reviews.llvm.org/D27852 llvm-svn: 290219
* [CrashReproducer] Collect headermap filesBruno Cardoso Lopes2016-12-111-0/+7
| | | | | | | | | | Include headermaps (.hmap files) in the .cache directory and add VFS entries. All headermaps are known after HeaderSearch setup, collect them right after. rdar://problem/27913709 llvm-svn: 289360
* Add some more asserts to clearly indicate that there are special casesChandler Carruth2016-11-041-1/+4
| | | | | | | | | | | | | | | | | which guarantee pointers are not null. These all seem to have useful properties and correlations to document, in one case we even had it in a comment but now it will also be an assert. This should prevent PVS-Studio from incorrectly claiming that there are a bunch of potential bugs here. But I feel really strongly that the PVS-Studio warnings that pointed at this code have a far too high false-positive rate to be entirely useful. These are just places where there did seem to be a useful invariant to document and verify with an assert. Several other places in the code were already correct and already have perfectly clear code documenting and validating their invariants, but still ran afoul of PVS-Studio. llvm-svn: 285985
* [Modules] Add 'no_undeclared_includes' module map attributeBruno Cardoso Lopes2016-10-211-7/+36
| | | | | | | | | | | | | The 'no_undeclared_includes' attribute should be used in a module to tell that only non-modular headers and headers from used modules are accepted. The main motivation behind this is to prevent dep cycles between system libraries (such as darwin) and libc++. Patch by Richard Smith! llvm-svn: 284797
* Turn FileManager DirectoryEntry::Name from raw pointer to StringRef (NFC)Mehdi Amini2016-10-111-1/+1
| | | | llvm-svn: 283856
* Store FileEntry::Filename as a StringRef instead of raw pointer (NFC)Mehdi Amini2016-10-101-8/+10
| | | | llvm-svn: 283815
* Use StringRef for MemoryBuffer identifier API (NFC)Mehdi Amini2016-10-011-1/+1
| | | | llvm-svn: 283043
* Module: add -fprebuilt-module-path to support loading prebuilt modules.Manman Ren2016-08-181-2/+20
| | | | | | | | | | | | | In this mode, there is no need to load any module map and the programmer can simply use "@import" syntax to load the module directly from a prebuilt module path. When loading from prebuilt module path, we don't support rebuilding of the module files and we ignore compatible configuration mismatches. rdar://27290316 Differential Revision: http://reviews.llvm.org/D23125 llvm-svn: 279096
* [NFC] Header cleanupMehdi Amini2016-07-181-1/+0
| | | | | | | | | | Summary: Removed unused headers, replaced some headers with forward class declarations Patch by: Eugene <claprix@yandex.ru> Differential Revision: https://reviews.llvm.org/D20100 llvm-svn: 275882
* Use the name of the file on disk to issue a new diagnostic about ↵Taewook Oh2016-06-131-6/+8
| | | | | | | | | | | non-portable #include and #import paths. Differential Revision: http://reviews.llvm.org/D19843 Corresponding LLVM change: http://reviews.llvm.org/D19842 Re-commit of r272562 after addressing clang-x86-win2008-selfhost failure. llvm-svn: 272584
* Revert r272562 for build bot failure (clang-x86-win2008-selfhost)Taewook Oh2016-06-131-8/+6
| | | | llvm-svn: 272572
* Use the name of the file on disk to issue a new diagnostic about ↵Taewook Oh2016-06-131-6/+8
| | | | | | | | | | | | | non-portable #include and #import paths. Differential Revision: http://reviews.llvm.org/D19843 Corresponding LLVM change: http://reviews.llvm.org/D19842 Re-commit after addressing issues with of generating too many warnings for Windows and asan test failures. Patch by Eric Niebler llvm-svn: 272562
* Revert commit r271708Taewook Oh2016-06-041-8/+6
| | | | llvm-svn: 271761
* Use the name of the file on disk to issue a new diagnostic about ↵Taewook Oh2016-06-031-6/+8
| | | | | | | | | | | non-portable #include and #import paths. Differential Revision: http://reviews.llvm.org/D19843 Corresponding LLVM change: http://reviews.llvm.org/D19842 Patch by Eric Niebler llvm-svn: 271708
* Apply clang-tidy's misc-move-constructor-init throughout Clang.Benjamin Kramer2016-05-271-2/+4
| | | | | | No functionality change intended, maybe a tiny performance improvement. llvm-svn: 270996
* NFC: simplify logic.Manman Ren2016-05-171-2/+2
| | | | llvm-svn: 269794
* Modules: set SystemHeader to true if we are building a system module.Manman Ren2016-05-171-3/+4
| | | | | | | | | | | | If we are processing a #include from a module build, we should treat it as a system header if we're building a system module. Passing an optional flag to HeaderSearch::LookupFile. Before this, the testing case will crash when accessing a freed FileEntry. rdar://26214027 llvm-svn: 269730
* [Modules] Use vfs for (recursive) directory iterationBruno Cardoso Lopes2016-05-161-8/+11
| | | | | | | | | | | | | | | | Clang performs directory walk while searching headers inside modules by using the ::sys::fs instead of ::vfs. This prevents any code that uses the VFS (e.g, reproducer scripts) to actually find such headers, since the VFS will never be searched for those. Change these places to use vfs::recursive_directory_iterator and vfs::directory_iterator instead. Differential Revision: http://reviews.llvm.org/D20266 rdar://problem/25880368 llvm-svn: 269661
* Remove unused LangOpts private variable in HeaderSearch.Samuel Antao2016-04-271-2/+1
| | | | | | Was causing warnings during the build. llvm-svn: 267805
OpenPOWER on IntegriCloud