summaryrefslogtreecommitdiffstats
path: root/clang/lib/Basic/Module.cpp
Commit message (Collapse)AuthorAgeFilesLines
* [coroutines] Support "coroutines" feature in module map requires clauseEric Fiselier2017-05-281-0/+1
| | | | | | | | | | | | | | Summary: In order for libc++ to add `<experimental/coroutine>` to its module map, there has to be a feature that can be used to detect if coroutines support is enabled in Clang. Reviewers: rsmith Reviewed By: rsmith Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D33538 llvm-svn: 304107
* Revert "[coroutines] Support "coroutines" feature in module map requires clause"Eric Fiselier2017-05-271-1/+0
| | | | | | This reverts commit r304054. llvm-svn: 304057
* [coroutines] Support "coroutines" feature in module map requires clauseEric Fiselier2017-05-271-0/+1
| | | | | | | | | | | | | | Summary: In order for libc++ to add `<experimental/coroutine>` to its module map, there has to be a feature that can be used to detect if coroutines support is enabled in Clang. Reviewers: rsmith Reviewed By: rsmith Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D33538 llvm-svn: 304054
* Modular Codegen: Add/use a bit in serialized function definitions to track ↵David Blaikie2017-04-111-1/+1
| | | | | | | | | | | | | | | | | | | | | whether they are the subject of modular codegen Some decls are created not where they are written, but in other module files/users (implicit special members and function template implicit specializations). To correctly identify them, use a bit next to the definition to track the modular codegen property. Discussed whether the module file bit could be omitted in favor of reconstituting from the modular codegen decls list - best guess today is that the efficiency improvement of not having to deserialize the whole list whenever any function is queried by a module user is worth it for the small size increase of this redundant (list + bit-on-def) representation. Reviewers: rsmith Differential Revision: https://reviews.llvm.org/D29901 llvm-svn: 299982
* Modules: Use hash of PCM content for SIGNATUREDuncan P. N. Exon Smith2017-03-131-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Change ASTFileSignature from a random 32-bit number to the hash of the PCM content. - Move definition ASTFileSignature to Basic/Module.h so Module and ASTSourceDescriptor can use it. - Change the signature from uint64_t to std::array<uint32_t,5>. - Stop using (saving/reading) the size and modification time of PCM files when there is a valid SIGNATURE. - Add UNHASHED_CONTROL_BLOCK, and use it to store the SIGNATURE record and other records that shouldn't affect the hash. Because implicit modules reuses the same file for multiple levels of -Werror, this includes DIAGNOSTIC_OPTIONS and DIAG_PRAGMA_MAPPINGS. This helps to solve a PCH + implicit Modules dependency issue: PCH files are handled by the external build system, whereas implicit modules are handled by internal compiler build system. This prevents invalidating a PCH when the compiler overwrites a PCM file with the same content (modulo the diagnostic differences). Design and original patch by Manman Ren! llvm-svn: 297655
* Prototype of modules codegenDavid Blaikie2017-01-301-1/+1
| | | | | | | | | | | | | | | | | | | | | 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] Add 'no_undeclared_includes' module map attributeBruno Cardoso Lopes2016-10-211-1/+8
| | | | | | | | | | | | | 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
* [Modules] Add 'freestanding' to the 'requires-declaration' feature-list.Elad Cohen2016-09-041-0/+1
| | | | | | | | | This adds support for modules that require (non-)freestanding environment, such as the compiler builtin mm_malloc submodule. Differential Revision: https://reviews.llvm.org/D23871 llvm-svn: 280613
* [Modules] Add 'gnuinlineasm' to the 'requires-declaration' feature-list.Bruno Cardoso Lopes2016-08-301-0/+1
| | | | | | | | | | | | | This adds support for modules that require (no-)gnu-inline-asm environment, such as the compiler builtin cpuid submodule. This is the gnu-inline-asm variant of https://reviews.llvm.org/D23871 Differential Revision: https://reviews.llvm.org/D23905 rdar://problem/26931199 llvm-svn: 280159
* [modules] Simplify code logic. NFC.Davide Italiano2016-03-091-6/+2
| | | | llvm-svn: 263060
* [Modules] Don't infinite recurse on implicit import of circular modules in ↵Ben Langmuir2016-02-111-0/+1
| | | | | | | | | | | | | | preamble Update the Preprocessor's VisibleModuleSet when typo-correction creates an implicit module import so that we won't accidentally write an invalid SourceLocation into the preamble AST. This would later lead to infinite recursion when loading the preamble AST because we use the value in ImportLocs to prevent visiting a module twice. rdar://problem/24440990 llvm-svn: 260543
* Annotate dump() methods with LLVM_DUMP_METHOD, addressing Richard Smith ↵Yaron Keren2016-01-291-1/+1
| | | | | | r259192 post commit comment. llvm-svn: 259232
* [modules] If we're given a module file, via -fmodule-file=, for a module, butRichard Smith2015-11-051-5/+6
| | | | | | | | | we can't load that file due to a configuration mismatch, and implicit module building is disabled, and the user turns off the error-by-default warning for that situation, then fall back to textual inclusion for the module rather than giving an error if any of its headers are included. llvm-svn: 252114
* [Modules] Add Darwin-specific compatibility module map parsing hacksBen Langmuir2015-08-131-0/+9
| | | | | | | | | | | | | | | | This preserves backwards compatibility for two hacks in the Darwin system module map files: 1. The use of 'requires excluded' to make headers non-modular, which should really be mapped to 'textual' now that we have this feature. 2. Silently removes a bogus cplusplus requirement from IOKit.avc. Once we start diagnosing missing requirements and headers on auto-imports these would have broken compatibility with existing Darwin SDKs. llvm-svn: 244912
* Add support for System z vector language extensionsUlrich Weigand2015-07-301-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The z13 vector facility has an associated language extension, closely modeled on AltiVec/VSX. The main differences are: - vector long, vector float and vector pixel are not supported - vector long long and vector double are supported (like VSX) - comparison operators return a vector rather than a scalar integer - shift operators behave like the OpenCL shift operators - vector bool is only supported as argument to certain operators; some operators allow mixing a bool with a non-bool vector This patch adds clang support for the extension. It is closely modelled on the AltiVec support. Similarly to the -faltivec option, there's a new -fzvector option to enable the extensions (as well as an -mzvector alias for compatibility with GCC). There's also a separate LangOpt. The extension as implemented here is intended to be compatible with the -mzvector extension recently implemented by GCC. Based on a patch by Richard Sandiford. Differential Revision: http://reviews.llvm.org/D11001 llvm-svn: 243642
* [Modules] Allow missing header before a missing requirementBen Langmuir2015-07-131-7/+11
| | | | | | | | | | | And make the module unavailable without breaking any parent modules. If there's a missing requirement after we've already seen a missing header, still update the IsMissingRequiement bit correctly. Also, diagnose missing requirements before missing headers, since the existence of the header is moot if there are missing requirements. llvm-svn: 242055
* Add a function to ExternalASTSource that returns a descriptor thatAdrian Prantl2015-06-301-1/+1
| | | | | | | abstracts the commonalities between modules and PCH files that are needed to emit debug info for a module or precompiled header. llvm-svn: 241083
* [modules] Retain the name as written for umbrella headers and directories, ↵Richard Smith2015-05-161-8/+8
| | | | | | rather than converting to an absolute path. No observable change expected, but this allows us to correctly compute the module for an umbrella header, which later changes will require. llvm-svn: 237508
* [modules] Start moving the module visibility information off the Module itself.Richard Smith2015-05-011-7/+50
| | | | | | | It has no place there; it's not a property of the Module, and it makes restoring the visibility set when we leave a submodule more difficult. llvm-svn: 236300
* [modules] Restrict the module use-declaration to only appear in top-levelRichard Smith2015-03-261-0/+13
| | | | | | | modules, and allow sub-modules of a module with a use-declaration to make use of the nominated modules. llvm-svn: 233323
* Add cc1 option '-fmodule-feature' to add custom values for 'requires' declsBen Langmuir2015-02-021-10/+15
| | | | | | | This allows clang-based tools to specify custom features that can be tested by the 'requires' declaration in a module map file. llvm-svn: 227868
* Handle [extern_c] attribute in module printerBen Langmuir2015-01-131-2/+5
| | | | | | | I'm not sure why we have OS.indent(Indent+2) for the system attribute, but presumably we want the same behaviour for all attributes... llvm-svn: 225802
* [modules] Track how 'header' directives were written in module map files,Richard Smith2014-12-021-12/+13
| | | | | | | | | | | | | rather than trying to extract this information from the FileEntry after the fact. This has a number of beneficial effects. For instance, diagnostic messages for failed module builds give a path relative to the "module root" rather than an absolute file path, and the contents of the module includes file is no longer dependent on what files the including TU happened to inspect prior to triggering the module build. llvm-svn: 223095
* [modules] Add support for 'textual header' directives.Richard Smith2014-10-221-19/+15
| | | | | | | | This allows a module to specify that it logically contains a file, but that said file is non-modular and intended for textual inclusion. This allows layering checks to work properly in the presence of such files. llvm-svn: 220448
* Refactor the module map file used for uniquing a module name out ofBen Langmuir2014-08-091-3/+7
| | | | | | | | | class Module. It's almost always going to be the same as getContainingModule() for top-level modules, so just add a map to cover the remaining cases. This lets us do less bookkeeping to keep the ModuleMap fields up to date. llvm-svn: 215268
* [C++11] Use 'nullptr'.Craig Topper2014-05-081-6/+6
| | | | llvm-svn: 208280
* Do not print inferred submodules explicitly in __inferred_module.mapBen Langmuir2014-04-231-4/+6
| | | | | | | | | | | | | | Otherwise including a header in your source file that is not included by framework's umbrella header will silently add an empty submodule with that name. is automatically translated to @import Foo.NotInModule; which then would have succeeded because the inferred module map contained an empty submodule called NotInModule. llvm-svn: 207024
* Initialize clang::Module::IsMissingRequirement. Fix msan issue and hopefully ↵Richard Smith2014-04-211-6/+6
| | | | | | some builder failures. llvm-svn: 206736
* Fix a hole with nested unavailable submodules from r206664Ben Langmuir2014-04-181-3/+4
| | | | | | | | If a module doesn't meet a requirement, neither do its submodules. If we don't propogate that, we might think it's an error to be missing a header in one of those submodules. llvm-svn: 206673
* Don't build modules with (submodules with) missing headersBen Langmuir2014-04-181-0/+5
| | | | | | | | Unless they are in submodules that aren't available anyway, due to requirements not being met. Also, mark children as unavailable when the parent is. llvm-svn: 206664
* Add more constness to module-related APIsDmitri Gribenko2014-04-181-1/+1
| | | | llvm-svn: 206595
* Allow multiple modules with the same name to coexist in the module cacheBen Langmuir2014-04-141-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | To differentiate between two modules with the same name, we will consider the path the module map file that they are defined by* part of the ‘key’ for looking up the precompiled module (pcm file). Specifically, this patch renames the precompiled module (pcm) files from cache-path/<module hash>/Foo.pcm to cache-path/<module hash>/Foo-<hash of module map path>.pcm In addition, I’ve taught the ASTReader to re-resolve the names of imported modules during module loading so that if the header search context changes between when a module was originally built and when it is loaded we can rebuild it if necessary. For example, if module A imports module B first time: clang -I /path/to/A -I /path/to/B ... second time: clang -I /path/to/A -I /different/path/to/B ... will now rebuild A as expected. * in the case of inferred modules, we use the module map file that allowed the inference, not the __inferred_module.map file, since the inferred file path is the same for every inferred module. llvm-svn: 206201
* Module [extern_c] attribute: inherit to submodules, don't write 'extern "C"'Richard Smith2014-03-081-0/+2
| | | | | | blocks when building in C mode, and serialize and deserialize the attribute. llvm-svn: 203317
* Add [extern_c] attribute for modules, allowing a C module to be imported ↵Richard Smith2014-03-021-4/+3
| | | | | | within an extern "C" block in C++ code. llvm-svn: 202615
* Modules: Don't warn upon missing headers while reading the module map.Daniel Jasper2013-12-171-1/+5
| | | | | | | | | | | | | | | Instead, mark the module as unavailable so that clang errors as soon as someone tries to build this module. This works towards the long-term goal of not stat'ing the header files at all while reading the module map and instead read them only when the module is being built (there is a corresponding FIXME in parseHeaderDecl()). However, it seems non-trivial to get there and this unblock us and moves us into the right direction. Also changed the implementation to reuse the same DiagnosticsEngine. llvm-svn: 197485
* Include non-explicit submodules in exported module listDmitri Gribenko2013-11-041-0/+10
| | | | | | | | | | | | | | | | This change fixes Richard's testcase for r193815. Now we include non-explicit submodules into the list of exports. The test failed previously because: - recursive_visibility_a1.inner is not imported (only recursive_visibility_a1 is), - thus the 'inner' submodule is not showing up in any of the import lists, - and because of this getExportedModules() is not returning the correct module set -- it only considers modules that are imported. The fix is to make Module::getExportedModules() include non-explicit submodules into the list of exports. llvm-svn: 194018
* Simplify computation of visible module set.Richard Smith2013-11-011-14/+5
| | | | llvm-svn: 193850
* Clang modules: collect exports recursivelyDmitri Gribenko2013-10-311-9/+17
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This change makes Module::buildVisibleModulesCache() collect exported modules recursively. While computing a set of exports, getExportedModules() iterates over the set of imported modules and filters it. But it does not consider the set of exports of those modules -- it is the responsibility of the caller to do this. Here is a certain instance of this issue. Module::isModuleVisible says that CoreFoundation.CFArray submodule is not visible from Cocoa. Why? - Cocoa imports Foundation. - Foundation has an export restriction: "export *". - Foundation imports CoreFoundation. (Just the top-level module.) - CoreFoundation exports CoreFoundation.CFArray. To decide which modules are visible from Cocoa, we collect all exported modules from immediate imports in Cocoa: > visibleModulesFro(Cocoa) = exported(Foundation) + exported(CoreData) + exported(AppKit) To find out which modules are exported, we filter imports according to restrictions: > exported(Foundation) = filterByModuleMapRestrictions(imports(Foundation)) Because Foundation imports CoreFoundation (not CoreFoundation.CFArray), the CFArray submodule is considered not exported from Foundation, and is not visible from Cocoa (according to Module::isModuleVisible). llvm-svn: 193815
* Allow a new syntax in a module requires-declaration:Richard Smith2013-10-281-11/+17
| | | | | | | | | | | | requires ! feature The purpose of this is to allow (for instance) the module map for /usr/include to exclude <tgmath.h> and <complex.h> when building in C++ (these headers are instead provided by the C++ standard library in this case, and the glibc C <tgmath.h> header would otherwise try to include <complex.h>, resulting in a module cycle). llvm-svn: 193549
* Module use declarations (II)Daniel Jasper2013-09-241-0/+14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Review: http://llvm-reviews.chandlerc.com/D1546. I have picked up this patch form Lawrence (http://llvm-reviews.chandlerc.com/D1063) and did a few changes. From the original change description (updated as appropriate): This patch adds a check that ensures that modules only use modules they have so declared. To this end, it adds a statement on intended module use to the module.map grammar: use module-id A module can then only use headers from other modules if it 'uses' them. This enforcement is off by default, but may be turned on with the new option -fmodules-decluse. When enforcing the module semantics, we also need to consider a source file part of a module. This is achieved with a compiler option -fmodule-name=<module-id>. The compiler at present only applies restrictions to the module directly being built. llvm-svn: 191283
* When we perform dependent name lookup during template instantiation, it's notRichard Smith2013-07-251-0/+18
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | sufficient to only consider names visible at the point of instantiation, because that may not include names that were visible when the template was defined. More generally, if the instantiation backtrace goes through a module M, then every declaration visible within M should be available to the instantiation. Any of those declarations might be part of the interface that M intended to export to a template that it instantiates. The fix here has two parts: 1) If we find a non-visible declaration during name lookup during template instantiation, check whether the declaration was visible from the defining module of all entities on the active template instantiation stack. The defining module is not the owning module in all cases: we look at the module in which a template was defined, not the module in which it was first instantiated. 2) Perform pending instantiations at the end of a module, not at the end of the translation unit. This is general goodness, since it significantly cuts down the amount of redundant work that is performed in every TU importing a module, and also implicitly adds the module containing the point of instantiation to the set of modules checked for declarations in a lookup within a template instantiation. There's a known issue here with template instantiations performed while building a module, if additional imports are added later on. I'll fix that in a subsequent commit. llvm-svn: 187167
* Use SmallVectorImpl::reverse_iterator instead of SmallVector to avoid ↵Craig Topper2013-07-081-2/+2
| | | | | | specifying the vector size. llvm-svn: 185784
* This patch adds new private headers to the module map. PrivateLawrence Crowl2013-06-201-2/+9
| | | | | | | headers may be included from within the module, but not from outside the module. llvm-svn: 184471
* <rdar://problem/12368093> Extend module maps with a 'conflict' declaration, ↵Douglas Gregor2013-03-201-0/+18
| | | | | | and warn when a newly-imported module conflicts with an already-imported module. llvm-svn: 177577
* Make sure that Module::ConfigMacrosExhaustive gets initialized and ↵Douglas Gregor2013-03-201-3/+4
| | | | | | | | | deserialized correctly. This fixes regressions introduced in r177466 that caused several module tests to fail sporadically. llvm-svn: 177481
* <rdar://problem/10796651> Introduce configuration macros into module maps.Douglas Gregor2013-03-201-1/+13
| | | | | | | | | | | | | | | | | | | | | | Configuration macros are macros that are intended to alter how a module works, such that we need to build different module variants for different values of these macros. A module can declare its configuration macros, in which case we will complain if the definition of a configation macro on the command line (or lack thereof) differs from the current preprocessor state at the point where the module is imported. This should eliminate some surprises when enabling modules, because "#define CONFIG_MACRO ..." followed by "#include <module/header.h>" would silently ignore the CONFIG_MACRO setting. At least it will no longer be silent about it. Configuration macros are eventually intended to help reduce the number of module variants that need to be built. When the list of configuration macros for a module is exhaustive, we only need to consider the settings for those macros when building/finding the module, which can help isolate modules for various project-specific -D flags that should never affect how modules are build (but currently do). llvm-svn: 177466
* [Modules] Resolve top-headers of modules lazily.Argyrios Kyrtzidis2013-03-131-0/+14
| | | | | | | | | | | This allows resolving top-header filenames of modules to FileEntries when we need them, not eagerly. Note that that this breaks ABI for libclang functions clang_Module_getTopLevelHeader / clang_Module_getNumTopLevelHeaders but this is fine because they are experimental and not widely used yet. llvm-svn: 176975
* [modules] Refactor code from ASTReader::makeModuleVisible() into a new function,Argyrios Kyrtzidis2013-02-191-0/+53
| | | | | | Module::getExportedModules() so it can be reused. llvm-svn: 175548
* Implement parsing, AST, (de-)serialization, and placeholder globalDouglas Gregor2013-01-141-0/+10
| | | | | | | | | | | | | | | | | | | | | | | | | metadata for linking against the libraries/frameworks for imported modules. The module map language is extended with a new "link" directive that specifies what library or framework to link against when a module is imported, e.g., link "clangAST" or link framework "MyFramework" Importing the corresponding module (or any of its submodules) will eventually link against the named library/framework. For now, I've added some placeholder global metadata that encodes the imported libraries/frameworks, so that we can test that this information gets through to the IR. The format of the data is still under discussion. llvm-svn: 172437
* Remove useless 'llvm::' qualifier from names like StringRef and others that areDmitri Gribenko2013-01-121-6/+6
| | | | | | brought into 'clang' namespace by clang/Basic/LLVM.h llvm-svn: 172323
OpenPOWER on IntegriCloud