summaryrefslogtreecommitdiffstats
path: root/clang/lib/Lex/ModuleMap.cpp
Commit message (Collapse)AuthorAgeFilesLines
* 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
* [Modules] Add 'no_undeclared_includes' module map attributeBruno Cardoso Lopes2016-10-211-14/+23
| | | | | | | | | | | | | 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
* Don't diagnose non-modular includes when we are not compiling a module.Manman Ren2016-08-261-1/+3
| | | | | | | | | | | | | | This is triggered when we are compiling an implementation of a module, it has relative includes to a VFS-mapped module with umbrella headers. Currently we will find the real path to headers under the umbrella directory, but the umbrella directories are using virtual path. rdar://27951255 Thanks Ben and Richard for reviewing the patch! Differential Revision: http://reviews.llvm.org/D23858 llvm-svn: 279838
* C++ Modules TS: add frontend support for building pcm files from moduleRichard Smith2016-08-261-1/+20
| | | | | | | interface files. At the moment, all declarations (and no macros) are exported, and 'export' declarations are not supported yet. llvm-svn: 279794
* [Lex] inferModuleFromLocation should do no work if there are no modulesDavid Majnemer2016-05-161-0/+3
| | | | | | | | | | | | getModuleContainingLocation ends up on the hot-path for typical C code which can lead to calls to getFileIDSlow. To speed this up, short circuit inferModuleFromLocation when there aren't any modules, implicit or otherwise. This shaves 4-5% build time when building the linux kernel. llvm-svn: 269687
* [Modules] Use vfs for (recursive) directory iterationBruno Cardoso Lopes2016-05-161-7/+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
* [ModuleMap][CrashReproducer] Collect headers from inner frameworksBruno Cardoso Lopes2016-05-131-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | (1) Collect headers under inner frameworks (frameworks inside other other frameworks). (2) Make sure we also collect the right header files inside them. More info on (2): Consider a dummy framework module B, with header Frameworks/B/B.h. Now consider that another framework A, with header Frameworks/A/A.h, has a layout with a inner framework Frameworks/A/Frameworks/B/B.h, where the "B/B.h" part is a symlink for Frameworks/B/B.h. Also assume that Frameworks/A/A.h includes <B/B.h>. When parsing header Frameworks/A/A.h, framework module lookup is performed in search for B, and it happens that "Frameworks/A/Frameworks/B/B.h" path is registered in the module instead of real "Frameworks/B/B.h". This occurs because "Frameworks/A/Frameworks/B/B.h" is scanned first by the FileManager, when looking for inner framework modules under Frameworks/A/Frameworks. This makes Frameworks/A/Frameworks/B/B.h the default cached named inside the FileManager for the B.h file UID. This leads to modules being built without consistent paths to underlying header files. This is usually not a problem in regular compilation flow, but it's an issue when running the crash reproducer. The issue is that clangs collect "Frameworks/A/Frameworks/B/B.h" but not "Frameworks/B/B.h" into the VFS, leading to err_mmap_umbrella_clash. So make sure we also collect the original header. Differential Revision: http://reviews.llvm.org/D20194 rdar://problem/25880368 llvm-svn: 269502
* [CrashReproducer] Change module map callback signature. NFCBruno Cardoso Lopes2016-05-061-1/+1
| | | | | | | | Use a StringRef instead of a FileEntry in the moduleMapAddHeader callback to allow more flexibility on what to collect on further patches. This changes the interface I introduced in r264971. llvm-svn: 268819
* [modules] When diagnosing a missing module import, suggest adding a #include ifRichard Smith2016-04-271-12/+7
| | | | | | | the current language doesn't have an import syntax and we can figure out a suitable file to include. llvm-svn: 267802
* [CrashReproducer] Add a module map callback for added headersBruno Cardoso Lopes2016-03-301-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The current ModuleDependencyCollector has a AST listener to collect header files present in loaded modules, but this isn't enough to collect all headers needed in the crash reproducer. One of the reasons is that the AST writer doesn't write symbolic link header paths in the pcm modules, this makes the listeners on the reader only able to collect the real files. Since the module maps could contain submodules that use headers which are symbolic links, not collecting those forbid the reproducer scripts to regen the modules. For instance: usr/include/module.map: ... module pthread { header "pthread.h" export * module impl { header "pthread_impl.h" export * } } ... usr/include/pthread/pthread_impl.h usr/include/pthread_impl.h -> pthread/pthread_impl.h The AST dump for the module above: <SUBMODULE_HEADER abbrevid=6/> blob data = 'pthread_impl.h' <SUBMODULE_TOPHEADER abbrevid=7/> blob data = '/<path_to_sdk>/usr/include/pthread/pthread_impl.h' Note that we don't have "usr/include/pthread_impl.h" which is requested by the module.map in case we want to reconstruct the module in the reproducer. The reason the original symbolic link path isn't used is because the headers are kept by name and requested through the FileManager, which unique files and returns the real path only. To fix that, add a callback to be invoked everytime a header is added while parsing module maps and hook that up to the module dependecy collector. This callback is only registered when generating the reproducer. Differential Revision: http://reviews.llvm.org/D18585 rdar://problem/24499339 llvm-svn: 264971
* [modules] Don't diagnose non-modular includes from modular files that areRichard Smith2016-03-141-1/+2
| | | | | | implementation units of modules rather than interface units. llvm-svn: 263449
* [Modules] Add stdatomic to the list of builtin headersBen Langmuir2016-03-091-0/+1
| | | | | | | | | | | | | Since it's provided by the compiler. This allows a system module map file to declare a module for it. No test change for cstd.m, since stdatomic.h doesn't function without a relatively complete stdint.h and stddef.h, which tests using this module don't provide. rdar://problem/24931246 llvm-svn: 263076
* [Modules] Modernize, use range-based loops.Davide Italiano2016-03-081-5/+2
| | | | llvm-svn: 262969
OpenPOWER on IntegriCloud