a4de17562d13d7a8188108243c4cfbd52f33229a |
|
04-Mar-2016 |
Pirama Arumuga Nainar <pirama@google.com> |
Update aosp/master clang for rebase to r256229 http://b/26987366 (cherry picked from commit 87d948ecccffea9e9e37d0d053b246e2d6d6c47b) Change-Id: I10ca401a280e905253aafabad9118693a2f24ffb
/external/clang/lib/Basic/Module.cpp
|
b6d6993e6e6d3daf4d9876794254d20a134e37c2 |
|
01-Jul-2015 |
Pirama Arumuga Nainar <pirama@google.com> |
Update aosp/master clang for rebase to r239765 Change-Id: I0393bcc952590a7226af8c4b58534a8ee5fd2d99
/external/clang/lib/Basic/Module.cpp
|
3ea9e33ea25e0c2b12db56418ba3f994eb662c04 |
|
08-Apr-2015 |
Pirama Arumuga Nainar <pirama@google.com> |
Update aosp/master clang for rebase to r233350 Change-Id: I12d4823f10bc9e445b8b86e7721b71f98d1df442
/external/clang/lib/Basic/Module.cpp
|
0e2c34f92f00628d48968dfea096d36381f494cb |
|
23-Mar-2015 |
Stephen Hines <srhines@google.com> |
Update aosp/master clang for rebase to r230699. Change-Id: I6a546ab3d4ae37119eebb735e102cca4f80ab520
/external/clang/lib/Basic/Module.cpp
|
176edba5311f6eff0cad2631449885ddf4fbc9ea |
|
01-Dec-2014 |
Stephen Hines <srhines@google.com> |
Update aosp/master Clang for rebase to r222490. Change-Id: Ic557ac55e97fbf6ee08771c7b7c3594777b0aefd
/external/clang/lib/Basic/Module.cpp
|
6bcf27bb9a4b5c3f79cb44c0e4654a6d7619ad89 |
|
29-May-2014 |
Stephen Hines <srhines@google.com> |
Update Clang for 3.5 rebase (r209713). Change-Id: I8c9133b0f8f776dc915f270b60f94962e771bc83
/external/clang/lib/Basic/Module.cpp
|
651f13cea278ec967336033dd032faef0e9fc2ec |
|
24-Apr-2014 |
Stephen Hines <srhines@google.com> |
Updated to Clang 3.5a. Change-Id: I8127eb568f674c2e72635b639a3295381fe8af82
/external/clang/lib/Basic/Module.cpp
|
86250895597e288c86ef08c2e824956ea9835fed |
|
04-Nov-2013 |
Dmitri Gribenko <gribozavr@gmail.com> |
Include non-explicit submodules in exported module list 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. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@194018 91177308-0d34-0410-b5e6-96231b3b80d8
/external/clang/lib/Basic/Module.cpp
|
8b1ab400d40b96f4634eb0c29986218c2905fda4 |
|
01-Nov-2013 |
Richard Smith <richard-llvm@metafoo.co.uk> |
Simplify computation of visible module set. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@193850 91177308-0d34-0410-b5e6-96231b3b80d8
/external/clang/lib/Basic/Module.cpp
|
bc64d35c4151dc34c21d0fc971b3aee0d28d83a3 |
|
31-Oct-2013 |
Dmitri Gribenko <gribozavr@gmail.com> |
Clang modules: collect exports recursively 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). git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@193815 91177308-0d34-0410-b5e6-96231b3b80d8
/external/clang/lib/Basic/Module.cpp
|
5794b53ad5b38b53c9eaf3a172354e63081ceb2f |
|
28-Oct-2013 |
Richard Smith <richard-llvm@metafoo.co.uk> |
Allow a new syntax in a module requires-declaration: 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). git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@193549 91177308-0d34-0410-b5e6-96231b3b80d8
/external/clang/lib/Basic/Module.cpp
|
ddd2dfc1d3f4a36cbe8cd775c588623a17049f9f |
|
24-Sep-2013 |
Daniel Jasper <djasper@google.com> |
Module use declarations (II) 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. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@191283 91177308-0d34-0410-b5e6-96231b3b80d8
/external/clang/lib/Basic/Module.cpp
|
b775100fea6d8955149897dae1adca50ca471d17 |
|
26-Jul-2013 |
Richard Smith <richard-llvm@metafoo.co.uk> |
When we perform dependent name lookup during template instantiation, it's not 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. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@187167 91177308-0d34-0410-b5e6-96231b3b80d8
/external/clang/lib/Basic/Module.cpp
|
163fbf810eaffc2c7b0170d91b6196b032911957 |
|
08-Jul-2013 |
Craig Topper <craig.topper@gmail.com> |
Use SmallVectorImpl::reverse_iterator instead of SmallVector to avoid specifying the vector size. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@185784 91177308-0d34-0410-b5e6-96231b3b80d8
/external/clang/lib/Basic/Module.cpp
|
bc3f628815b3841dc99109e7f67f9afa7793bc94 |
|
20-Jun-2013 |
Lawrence Crowl <crowl@google.com> |
This patch adds new private headers to the module map. Private headers may be included from within the module, but not from outside the module. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@184471 91177308-0d34-0410-b5e6-96231b3b80d8
/external/clang/lib/Basic/Module.cpp
|
906d66acc5cf2679453e10a4f0a67feedd765b21 |
|
20-Mar-2013 |
Douglas Gregor <dgregor@apple.com> |
<rdar://problem/12368093> Extend module maps with a 'conflict' declaration, and warn when a newly-imported module conflicts with an already-imported module. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@177577 91177308-0d34-0410-b5e6-96231b3b80d8
/external/clang/lib/Basic/Module.cpp
|
970e441671be130c9a12b7eda2a0b795008812a5 |
|
20-Mar-2013 |
Douglas Gregor <dgregor@apple.com> |
Make sure that Module::ConfigMacrosExhaustive gets initialized and deserialized correctly. This fixes regressions introduced in r177466 that caused several module tests to fail sporadically. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@177481 91177308-0d34-0410-b5e6-96231b3b80d8
/external/clang/lib/Basic/Module.cpp
|
63a726870b486e0470c3a4b11cf62bab8be00b73 |
|
20-Mar-2013 |
Douglas Gregor <dgregor@apple.com> |
<rdar://problem/10796651> Introduce configuration macros into module maps. 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). git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@177466 91177308-0d34-0410-b5e6-96231b3b80d8
/external/clang/lib/Basic/Module.cpp
|
c1d22393628a145e54396c0ac66e9625d13a7658 |
|
13-Mar-2013 |
Argyrios Kyrtzidis <akyrtzi@gmail.com> |
[Modules] Resolve top-headers of modules lazily. 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. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@176975 91177308-0d34-0410-b5e6-96231b3b80d8
/external/clang/lib/Basic/Module.cpp
|
21a0004d80f50808ee343ae70092f6260a4c9477 |
|
19-Feb-2013 |
Argyrios Kyrtzidis <akyrtzi@gmail.com> |
[modules] Refactor code from ASTReader::makeModuleVisible() into a new function, Module::getExportedModules() so it can be reused. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@175548 91177308-0d34-0410-b5e6-96231b3b80d8
/external/clang/lib/Basic/Module.cpp
|
b6cbe517237c3c223beb064d60d5b49e56d65c06 |
|
14-Jan-2013 |
Douglas Gregor <dgregor@apple.com> |
Implement parsing, AST, (de-)serialization, and placeholder global 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. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@172437 91177308-0d34-0410-b5e6-96231b3b80d8
/external/clang/lib/Basic/Module.cpp
|
cfa88f893915ceb8ae4ce2f17c46c24a4d67502f |
|
12-Jan-2013 |
Dmitri Gribenko <gribozavr@gmail.com> |
Remove useless 'llvm::' qualifier from names like StringRef and others that are brought into 'clang' namespace by clang/Basic/LLVM.h git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@172323 91177308-0d34-0410-b5e6-96231b3b80d8
/external/clang/lib/Basic/Module.cpp
|
80ad52f327b532bded5c5b0ee38779d841c6cd35 |
|
02-Jan-2013 |
Richard Smith <richard-llvm@metafoo.co.uk> |
s/CPlusPlus0x/CPlusPlus11/g git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@171367 91177308-0d34-0410-b5e6-96231b3b80d8
/external/clang/lib/Basic/Module.cpp
|
55fc873017f10f6f566b182b70f6fc22aefa3464 |
|
04-Dec-2012 |
Chandler Carruth <chandlerc@gmail.com> |
Sort all of Clang's files under 'lib', and fix up the broken headers uncovered. This required manually correcting all of the incorrect main-module headers I could find, and running the new llvm/utils/sort_includes.py script over the files. I also manually added quite a few missing headers that were uncovered by shuffling the order or moving headers up to be main-module-headers. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@169237 91177308-0d34-0410-b5e6-96231b3b80d8
/external/clang/lib/Basic/Module.cpp
|
2b49d1f0ad790a8a5d514af1be211591a746cb73 |
|
15-Oct-2012 |
Douglas Gregor <dgregor@apple.com> |
Introduce the notion of excluded headers into the module map description. Previously, one could emulate this behavior by placing the header in an always-unavailable submodule, but Argyrios guilted me into expressing this idea properly. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@165921 91177308-0d34-0410-b5e6-96231b3b80d8
/external/clang/lib/Basic/Module.cpp
|
e2ac16b09ea66ad955752381b82fb8719d003e5e |
|
29-Sep-2012 |
Argyrios Kyrtzidis <akyrtzi@gmail.com> |
In the Module class, add a reference to the corresponding AST file. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@164873 91177308-0d34-0410-b5e6-96231b3b80d8
/external/clang/lib/Basic/Module.cpp
|
2f04f1843ca0ffca13b8b0d4dadd1f50dffb38b8 |
|
02-Feb-2012 |
Douglas Gregor <dgregor@apple.com> |
Back out my heinous hack that tricked the module generation mechanism into using non-absolute system includes (<foo>)... ... and introduce another hack that is simultaneously more heineous and more effective. We whitelist Clang-supplied headers that augment or override system headers (such as float.h, stdarg.h, and tgmath.h). For these headers, Clang does not provide a module mapping. Instead, a system-supplied module map can refer to these headers in a system module, and Clang will look both in its own include directory and wherever the system-supplied module map suggests, then adds either or both headers. The end result is that Clang-supplied headers get merged into the system-supplied module for the C standard library. As a drive-by, fix up a few dependencies in the _Builtin_instrinsics module. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@149611 91177308-0d34-0410-b5e6-96231b3b80d8
/external/clang/lib/Basic/Module.cpp
|
e727d21d3fd5f6f68d9e7a260bbf84dc2fc8ae3a |
|
30-Jan-2012 |
Douglas Gregor <dgregor@apple.com> |
Introduce TargetInfo::hasFeature() to query various feature names in each of the targets. Use this for module requirements, so that we can pin the availability of certain modules to certain target features, e.g., provide a module for xmmintrin.h only when SSE support is available. Use these feature names to provide a nearly-complete module map for Clang's built-in headers. Only mm_alloc.h and unwind.h are missing, and those two are fairly specialized at the moment. Finishes <rdar://problem/10710060>. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@149227 91177308-0d34-0410-b5e6-96231b3b80d8
/external/clang/lib/Basic/Module.cpp
|
dc58aa71026cce539ca9b5c2c52cc4efc7bd77fe |
|
30-Jan-2012 |
Douglas Gregor <dgregor@apple.com> |
Thread a TargetInfo through to the module map; we'll need it for target-specific module requirements. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@149224 91177308-0d34-0410-b5e6-96231b3b80d8
/external/clang/lib/Basic/Module.cpp
|
a1f1fad8b60e1cb9d21a40a37f2e03150bcbeb6f |
|
27-Jan-2012 |
Douglas Gregor <dgregor@apple.com> |
Introduce module attributes into the module map grammar, along with a single attribute ("system") that allows us to mark a module as being a "system" module. Each of the headers that makes up a system module is considered to be a system header, so that we (for example) suppress warnings there. If a module is being inferred for a framework, and that framework directory is within a system frameworks directory, infer it as a system framework. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@149143 91177308-0d34-0410-b5e6-96231b3b80d8
/external/clang/lib/Basic/Module.cpp
|
7530c034c0c71a64c5a9173206d9742ae847af8b |
|
17-Jan-2012 |
David Blaikie <dblaikie@gmail.com> |
Remove unreachable code in Clang. (replace with llvm_unreachable where appropriate or when GCC requires it) git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@148292 91177308-0d34-0410-b5e6-96231b3b80d8
/external/clang/lib/Basic/Module.cpp
|
b7a7819473709c01ea024a2dc15e99d38f0f8760 |
|
05-Jan-2012 |
Douglas Gregor <dgregor@apple.com> |
Store the submodules of a module in source order, as they are stored in the module map. This provides a bit more predictability for the user, as well as eliminating the need to sort the submodules when serializing them. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@147564 91177308-0d34-0410-b5e6-96231b3b80d8
/external/clang/lib/Basic/Module.cpp
|
51f564f80d9f71e175635b452ffeeeff899e9bf1 |
|
31-Dec-2011 |
Douglas Gregor <dgregor@apple.com> |
Implement support for module requirements, which indicate the language features needed for a particular module to be available. This allows mixed-language modules, where certain headers only work under some language variants (e.g., in C++, std.tuple might only be available in C++11 mode). git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@147387 91177308-0d34-0410-b5e6-96231b3b80d8
/external/clang/lib/Basic/Module.cpp
|
489ad43b77c10a98df80f1395de81e3f52697e76 |
|
08-Dec-2011 |
Douglas Gregor <dgregor@apple.com> |
Tweak the syntax of umbrella headers, so that "umbrella" is treated as a modifier for a header declarartion, e.g., umbrella header "headername" Collapse the umbrella-handling code in the parser into the header-handling code, so we don't duplicate the header-search logic. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@146159 91177308-0d34-0410-b5e6-96231b3b80d8
/external/clang/lib/Basic/Module.cpp
|
10694cee2588442bee1e717f5042c58ffee25279 |
|
08-Dec-2011 |
Douglas Gregor <dgregor@apple.com> |
Within the module representation, generalize the notion of an umbrella header to also support umbrella directories. The umbrella directory for an umbrella header is the directory in which the umbrella header resides. No functionality change yet, but it's coming. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@146158 91177308-0d34-0410-b5e6-96231b3b80d8
/external/clang/lib/Basic/Module.cpp
|
1e12368db12005ddd92fd9188c86383fe30ef443 |
|
05-Dec-2011 |
Douglas Gregor <dgregor@apple.com> |
Parse inferred submodules in module maps, track their contents in Module, and (de-)serialize this information. Semantics of inferred submodules to follow. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@145864 91177308-0d34-0410-b5e6-96231b3b80d8
/external/clang/lib/Basic/Module.cpp
|
f4ac17e51f9841e05e5cc17d65f27f0d1cc62fcb |
|
05-Dec-2011 |
Douglas Gregor <dgregor@apple.com> |
Fix printing of wildcard exports. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@145812 91177308-0d34-0410-b5e6-96231b3b80d8
/external/clang/lib/Basic/Module.cpp
|
0adaa880993ad23186c87c7f98e7a3fd2697742c |
|
05-Dec-2011 |
Douglas Gregor <dgregor@apple.com> |
Implement support for wildcard exports in modules, allowing a module to re-export anything that it imports. This opt-in feature makes a module behave more like a header, because it can be used to re-export the transitive closure of a (sub)module's dependencies. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@145811 91177308-0d34-0410-b5e6-96231b3b80d8
/external/clang/lib/Basic/Module.cpp
|
af13bfc3b40aa4a46f4e71d200ecfb10f45297fc |
|
02-Dec-2011 |
Douglas Gregor <dgregor@apple.com> |
Implement (de-)serialization of the set of exported modules in a module map. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@145695 91177308-0d34-0410-b5e6-96231b3b80d8
/external/clang/lib/Basic/Module.cpp
|
1a4761edca58c6b559de825b9abfb66f7f1ba94a |
|
01-Dec-2011 |
Douglas Gregor <dgregor@apple.com> |
Promote ModuleMap::Module to a namespace-scope class in the Basic library, since modules cut across all of the libraries. Rename serialization::Module to serialization::ModuleFile to side-step the annoying naming conflict. Prune a bunch of ModuleMap.h includes that are no longer needed (most files only needed the Module type). git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@145538 91177308-0d34-0410-b5e6-96231b3b80d8
/external/clang/lib/Basic/Module.cpp
|