summaryrefslogtreecommitdiffstats
path: root/clang/lib/Lex/HeaderSearch.cpp
Commit message (Collapse)AuthorAgeFilesLines
* [Preprocessor] Add a note with framework location for "file not found" error.Volodymyr Sapsai2019-02-051-11/+20
| | | | | | | | | | | | | | | | | | | | | | | | | 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
* [Support] Remove error return value from one overload of fs::make_absolutePavel Labath2019-01-161-3/+2
| | | | | | | | | | | | | | | | | | | | | | Summary: The version of make_absolute which accepted a specific directory to use as the "base" for the computation could never fail, even though it returned a std::error_code. The reason for that seems to be historical -- the CWD flavour (which can fail due to failure to retrieve CWD) was there first, and the new version was implemented by extending that. This removes the error return value from the non-CWD overload and reimplements the CWD version on top of that. This enables us to remove some dead code where people were pessimistically trying to handle the errors returned from this function. Reviewers: zturner, sammccall Subscribers: hiraditya, kristina, llvm-commits Differential Revision: https://reviews.llvm.org/D56599 llvm-svn: 351317
* [HeaderSearch] loadSubdirectoryModuleMaps should respect -working-directoryAlex Lorenz2018-11-141-1/+3
| | | | | | | | | | | Include search paths can be relative paths. The loadSubdirectoryModuleMaps function should account for that and respect the -working-directory parameter given to Clang. rdar://46045849 Differential Revision: https://reviews.llvm.org/D54503 llvm-svn: 346822
* Lift VFS from clang to llvm (NFC)Jonas Devlieghere2018-10-101-5/+6
| | | | | | | | | | | | | | | | | | | This patch moves the virtual file system form clang to llvm so it can be used by more projects. Concretely the patch: - Moves VirtualFileSystem.{h|cpp} from clang/Basic to llvm/Support. - Moves the corresponding unit test from clang to llvm. - Moves the vfs namespace from clang::vfs to llvm::vfs. - Formats the lines affected by this change, mostly this is the result of the added llvm namespace. RFC on the mailing list: http://lists.llvm.org/pipermail/llvm-dev/2018-October/126657.html Differential revision: https://reviews.llvm.org/D52783 llvm-svn: 344140
* Fix an assert in -Wquoted-include-in-framework-headerErik Pilkington2018-09-201-1/+1
| | | | | | | | Fixes rdar://43692300 Differential revision: https://reviews.llvm.org/D52253 llvm-svn: 342679
* [VFS] vfs::directory_iterator yields path and file type instead of full StatusSam McCall2018-09-141-7/+6
| | | | | | | | | | | | | | | | | | | | | | | Summary: Most callers I can find are using only `getName()`. Type is used by the recursive iterator. Now we don't have to call stat() on every listed file (on most platforms). Exceptions are e.g. Solaris where readdir() doesn't include type information. On those platforms we'll still stat() - see D51918. The result is significantly faster (stat() can be slow). My motivation: this may allow us to improve clang IO on large TUs with long include search paths. Caching readdir() results may allow us to skip many stat() and open() operations on nonexistent files. Reviewers: bkramer Subscribers: fedor.sergeev, cfe-commits Differential Revision: https://reviews.llvm.org/D51921 llvm-svn: 342232
* [Lex] Make HeaderMaps a unique_ptr vectorFangrui Song2018-08-201-10/+4
| | | | | | | | | | | | Summary: unique_ptr makes the ownership clearer than a raw pointer container. Reviewers: Eugene.Zelenko, dblaikie Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D50945 llvm-svn: 340198
* 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
OpenPOWER on IntegriCloud