summaryrefslogtreecommitdiffstats
path: root/clang/lib/Lex/ModuleMap.cpp
Commit message (Collapse)AuthorAgeFilesLines
* ModuleMap::findHeader - fix null dereference warning. NFCI.Simon Pilgrim2019-11-031-1/+1
| | | | We were checking M for a null value after we'd already dereferenced it multiple times.
* [clang] Adopt new FileManager error-returning APIsHarlan Haskins2019-08-011-31/+42
| | | | | | | Update the callers of FileManager::getFile and FileManager::getDirectory to handle the new llvm::ErrorOr-returning methods. Signed-off-by: Harlan Haskins <harlan@apple.com> llvm-svn: 367616
* [c++2a] Add semantic support for private module fragments.Richard Smith2019-04-181-1/+11
| | | | llvm-svn: 358713
* Basic: Return a reference from FileManager::getVirtualFileSystem, NFCDuncan P. N. Exon Smith2019-03-261-2/+2
| | | | | | | | | | FileManager constructs a VFS in its constructor if it isn't passed one, and there's no way to reset it. Make that contract clear by returning a reference from its accessor. https://reviews.llvm.org/D59388 llvm-svn: 357038
* 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
* Add vtable anchor to classes.Richard Trieu2018-12-291-0/+2
| | | | llvm-svn: 350143
* Reapply "Fix regression in behavior of clang -x c++-header -fmodule-name=XXX"Benjamin Kramer2018-11-051-1/+1
| | | | | | | | | | | | | This reverts commit r345963. We have a path forward now. Original commit message: The driver accidentally stopped passing the input filenames on to -cc1 in this mode due to confusion over what action was being requested. This change also fixes a couple of crashes I encountered when passing multiple files to such a -cc1 invocation. llvm-svn: 346130
* Revert "Fix regression in behavior of clang -x c++-header -fmodule-name=XXX"Ilya Biryukov2018-11-021-1/+1
| | | | | | | | | | This reverts commit r345803 and r345915 (a follow-up fix to r345803). Reason: r345803 blocks our internal integrate because of the new warnings showing up in too many places. The fix is actually correct, we will reland it after figuring out how to integrate properly. llvm-svn: 345963
* Fix regression in behavior of clang -x c++-header -fmodule-name=XXXRichard Smith2018-11-011-1/+1
| | | | | | | | | | | | -fsyntax-only. The driver accidentally stopped passing the input filenames on to -cc1 in this mode due to confusion over what action was being requested. This change also fixes a couple of crashes I encountered when passing multiple files to such a -cc1 invocation. llvm-svn: 345803
* Lift VFS from clang to llvm (NFC)Jonas Devlieghere2018-10-101-6/+8
| | | | | | | | | | | | | | | | | | | 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
* [modules] Frontend support for building a header module from a list ofRichard Smith2018-09-151-8/+31
| | | | | | headaer files. llvm-svn: 342304
* [VFS] vfs::directory_iterator yields path and file type instead of full StatusSam McCall2018-09-141-5/+4
| | | | | | | | | | | | | | | | | | | | | | | 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
* Remove trailing spaceFangrui Song2018-07-301-89/+89
| | | | | | sed -Ei 's/[[:space:]]+$//' include/**/*.{def,h,td} lib/**/*.{cpp,h} llvm-svn: 338291
* [Modules] Improve .Private fix-its to handle 'explicit' and 'framework'Bruno Cardoso Lopes2018-06-151-11/+27
| | | | | | | | | | When in the context of suggestion the fix-it from .Private to _Private for private modules, trim off the 'explicit' and add 'framework' when appropriate. rdar://problem/41030554 llvm-svn: 334859
* Fix unused variable warning from r333718 Erich Keane2018-06-011-1/+1
| | | | llvm-svn: 333752
* [Modules] Warning for module declarations lacking 'framework' qualifierBruno Cardoso Lopes2018-06-011-25/+57
| | | | | | | | | | | | | | | When a module declaration for a framework lacks the 'framework' qualifier, the listed headers aren't found (because there's no trigger for the special framework style path lookup) and the module is silently not built. This leads to frameworks not being modularized by accident, which is pretty bad. Add a warning and suggest the user to add the 'framework' qualifier when we can prove that it's the case. rdar://problem/39193062 llvm-svn: 333718
* Remove \brief commands from doxygen comments.Adrian Prantl2018-05-091-38/+38
| | | | | | | | | | | | | | | | | | | 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
* Record whether a module came from a private module mapJordan Rose2018-04-201-3/+6
| | | | | | | | | | | Right now we only use this information in one place, immediately after we calculate it, but it's still nice information to have. The Swift project is going to use this to tidy up its "API notes" feature (see past discussion on cfe-dev that never quite converged). Reviewed by Bruno Cardoso Lopes. llvm-svn: 330452
* Use export_as for autolinking frameworksBruno Cardoso Lopes2018-04-161-0/+20
| | | | | | | | | | | | | | | | framework module SomeKitCore { ... export_as SomeKit } Given the module above, while generting autolink information during codegen, clang should to emit '-framework SomeKitCore' only if SomeKit was not imported in the relevant TU, otherwise it should use '-framework SomeKit' instead. rdar://problem/38269782 llvm-svn: 330152
* [Modules] Improve fixit for framework private module mapsBruno Cardoso Lopes2018-03-301-6/+11
| | | | | | | | | The wrong source range was being provided in some case, fix that to get a better fixit. rdar://problem/38520199 llvm-svn: 328857
* Make module use diagnostics refer to the top-level moduleDaniel Jasper2018-02-241-2/+2
| | | | | | | | | | All use declarations need to be directly placed in the top-level module anyway, knowing the submodule doesn't really help. The header that has the offending #include can easily be seen in the diagnostics source location. Review: https://reviews.llvm.org/D43673 llvm-svn: 326023
* Track shadow modules with a generation counter.Bruno Cardoso Lopes2018-01-051-25/+16
| | | | | | | | | | 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-32/+71
| | | | | | | | | | | | | | | | | | | | | | | | | | | | 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-68/+32
| | | | | | | | | | | 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-32/+68
| | | | | | | | | | | | | | | | | | | | | | | | | | | | 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-35/+63
| | | | | | | | | | | | | | | | 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-29/+54
| | | | | | minor fixes (NFC). llvm-svn: 319986
* [Module map] Introduce a private module re-export directive.Douglas Gregor2017-09-141-0/+44
| | | | | | | | | | | | | Introduce a new "export_as" directive for top-level modules, which indicates that the current module is a "private" module whose symbols will eventually be exported through the named "public" module. This is in support of a common pattern in the Darwin ecosystem where a single public framework is constructed of several private frameworks, with (currently) header duplication and some support from the linker. Addresses rdar://problem/34438420. llvm-svn: 313316
* Fix memory leak after r312467. The ModuleMap is the owner of the global ↵Richard Smith2017-09-051-6/+10
| | | | | | module object until it's reparented under a real module. llvm-svn: 312580
* Implement Itanium name mangling support for C++ Modules TS.Richard Smith2017-09-041-1/+12
| | | | | | | | | | | | This follows the scheme agreed with Nathan Sidwell, which can be found here: https://gcc.gnu.org/wiki/cxx-modules?action=AttachFile This will be proposed to the itanium-cxx-abi list once we have some experience with how well it works; the ABI for this TS should be considered unstable until it is part of the Itanium C++ ABI. llvm-svn: 312467
* Track the set of module maps read while building a .pcm file and reload ↵Richard Smith2017-06-291-1/+2
| | | | | | those when preprocessing from that .pcm file. llvm-svn: 306628
* Support lazy stat'ing of files referenced by module maps.Richard Smith2017-06-021-84/+250
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Factor resolving of header directives -> files out of module map parser.Richard Smith2017-05-261-97/+104
| | | | llvm-svn: 303945
* Remove last (unnecessary) use of mapping from SourceLocation to Module andRichard Smith2017-05-191-33/+0
| | | | | | | | | remove the mechanism for doing so. This mechanism was incorrect in the presence of preprocessed modules (and #pragma clang module begin/end). llvm-svn: 303469
* [Modules] Allow umbrella frameworks to define private submodules for ↵Bruno Cardoso Lopes2017-05-091-2/+4
| | | | | | | | | | | | subframeworks In r298391 we fixed the umbrella framework model to work when submodules named "Private" are used. This complements the work by allowing the umbrella framework model to work in general. rdar://problem/31790067 llvm-svn: 302491
* If we are building a module, and we read a second description of the sameRichard Smith2017-05-081-1/+13
| | | | | | | | module from a different module map, ignore it. This happens during builds of preprocessed modules (where it is harmless). llvm-svn: 302463
* Add support for building modules from preprocessed source.Richard Smith2017-05-051-9/+49
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* [modules ts] Diagnose 'export' declarations outside of a module interface.Richard Smith2017-04-241-0/+1
| | | | llvm-svn: 301271
* PR30508: Downgrade error to warning if the umbrella folder doesn't exist.Vassil Vassilev2017-04-181-2/+1
| | | | | | Patch by Yuka Takahashi (D32119)! llvm-svn: 300594
* Modular Codegen: Separate flags for function and debug info supportDavid Blaikie2017-04-121-1/+0
| | | | | | | | | | This allows using and testing these two features separately. (noteably, debug info is, so far as I know, always a win (basically). But function modular codegen is currently a loss for highly optimized code - where most of the linkonce_odr definitions are optimized away, so providing weak_odr definitions is only overhead) llvm-svn: 300104
* [Modules] Find PrivateHeaders when looking into subframeworksBruno Cardoso Lopes2017-03-211-7/+13
| | | | | | | | | Fix the current parsing of subframeworks in modulemaps to lookup for headers based on whether they are frameworks. rdar://problem/30563982 llvm-svn: 298391
* Fix modules codegen to be compatible with modules-tsDavid Blaikie2017-01-311-1/+0
| | | | | | | | | | | | | | | | | The Module::WithCodegen flag was only being set when the module was parsed from a ModuleMap. Instead set it late, in the ASTWriter to match the layer where the MODULAR_CODEGEN_DECLs list is determined (the WithCodegen flag essentially means "are this module's decls in MODULAR_CODEGEN_DECLs"). When simultaneous emission of AST file and modular object is implemented this may need to change - the Module::WithCodegen flag will need to be set earlier, and ideally the MODULAR_CODEGEN_DECLs gathering will consult this flag (that's not possible right now since Decls destined for an AST File don't have a Module - only if they're /read/ from a Module is that true - I expect that would need to change as well). llvm-svn: 293692
* Prototype of modules codegenDavid Blaikie2017-01-301-5/+8
| | | | | | | | | | | | | | | | | | | | | First pass at generating weak definitions of inline functions from module files (& skipping (-O0) or emitting available_externally (optimizations) definitions where those modules are used). External functions defined in modules are emitted into the modular object file as well (this may turn an existing ODR violation (if that module were imported into multiple translations) into valid/linkable code). Internal symbols (static functions, for example) are not correctly supported yet. The symbol will be produced, internal, in the modular object - unreferenceable from the users. Reviewers: rsmith Differential Revision: https://reviews.llvm.org/D28845 llvm-svn: 293456
* [Modules] Fix misleading warning about missing textual header in umbrella headerBruno Cardoso Lopes2017-01-121-2/+12
| | | | | | | | | | | | | | | | | | | | | | | | | When a textual header is present inside a umbrella dir but not in the header, we get the misleading warning: warning: umbrella header for module 'FooFramework' does not include header 'Baz_Private.h' The module map in question: framework module FooFramework { umbrella header "FooUmbrella.h" export * module * { export * } module Private { textual header "Baz_Private.h" } } Fix this by taking textual headers into account. llvm-svn: 291794
* [Modules] Support #import when entering files with modulesBruno Cardoso Lopes2017-01-111-3/+3
| | | | | | | | | | | | 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
* Use after move bug fixesPiotr Padlewski2016-12-231-1/+1
| | | | | | | | | | | | Summary: Bunch of fixed bugs in Clang after running misc-use-after-move in clang-tidy. Reviewers: rsmith, mboehme Subscribers: cfe-commits, klimek Differential Revision: https://reviews.llvm.org/D27752 llvm-svn: 290424
* [modules] Handle modules with nonstandard names in module.private.modulemapsGraydon Hoare2016-12-211-0/+36
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* [Modules] Replace arrays with init lists.Benjamin Kramer2016-11-151-9/+5
| | | | | | | Thi way the compiler can pick the optimal storage duration. It's also more readable. No functional change intended. llvm-svn: 287005
* Treat module headers wrapped by our builtin headers as implicitly being textualRichard Smith2016-10-261-5/+9
| | | | | | | | | | headers. We previously got this check backwards and treated the wrapper header as being textual. This is important because our wrapper headers sometimes inject macros into the system headers that they #include_next, and sometimes replace them entirely. llvm-svn: 285152
* Module: improve the diagnostic message for include of non-modular header.Manman Ren2016-10-211-1/+2
| | | | | | | | Emit the actual path to the non-modular include. rdar://28897010 llvm-svn: 284897
OpenPOWER on IntegriCloud