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/include/clang/Lex/ModuleMap.h
|
b6d6993e6e6d3daf4d9876794254d20a134e37c2 |
|
01-Jul-2015 |
Pirama Arumuga Nainar <pirama@google.com> |
Update aosp/master clang for rebase to r239765 Change-Id: I0393bcc952590a7226af8c4b58534a8ee5fd2d99
/external/clang/include/clang/Lex/ModuleMap.h
|
0e2c34f92f00628d48968dfea096d36381f494cb |
|
23-Mar-2015 |
Stephen Hines <srhines@google.com> |
Update aosp/master clang for rebase to r230699. Change-Id: I6a546ab3d4ae37119eebb735e102cca4f80ab520
/external/clang/include/clang/Lex/ModuleMap.h
|
176edba5311f6eff0cad2631449885ddf4fbc9ea |
|
01-Dec-2014 |
Stephen Hines <srhines@google.com> |
Update aosp/master Clang for rebase to r222490. Change-Id: Ic557ac55e97fbf6ee08771c7b7c3594777b0aefd
/external/clang/include/clang/Lex/ModuleMap.h
|
6bcf27bb9a4b5c3f79cb44c0e4654a6d7619ad89 |
|
29-May-2014 |
Stephen Hines <srhines@google.com> |
Update Clang for 3.5 rebase (r209713). Change-Id: I8c9133b0f8f776dc915f270b60f94962e771bc83
/external/clang/include/clang/Lex/ModuleMap.h
|
651f13cea278ec967336033dd032faef0e9fc2ec |
|
24-Apr-2014 |
Stephen Hines <srhines@google.com> |
Updated to Clang 3.5a. Change-Id: I8127eb568f674c2e72635b639a3295381fe8af82
/external/clang/include/clang/Lex/ModuleMap.h
|
ee0cd37fe4a9f4e2ee73ae34cf93c410cb299a82 |
|
24-Oct-2013 |
Manuel Klimek <klimek@google.com> |
Use the same SourceManager for ModuleMaps and compilations. This allows using virtual file mappings on the original SourceManager to map in virtual module.map files. Without this patch, the ModuleMap search will find a module.map file (as the FileEntry exists in the FileManager), but will be unable to get the content from the SourceManager (as ModuleMap previously created its own SourceManager). Two problems needed to be fixed which this patch exposed: 1. Storing the inferred module map When writing out a module, the ASTWriter stores the names of the files in the main source manager; when loading the AST again, the ASTReader errs out if such a file is found missing, unless it is overridden. Previously CompilerInstance's compileModule method would store the inferred module map to a temporary file; the problem with this approach is that now that the module map is handled by the main source manager, the ASTWriter stores the name of the temporary module map as source to the compilation; later, when the module is loaded, the temporary file has already been deleted, which leads to a compilation error. This patch changes the inferred module map to instead inject a virtual file into the source manager. This both saves some disk IO, and works with how the ASTWriter/ASTReader handle overridden source files. 2. Changing test input in test/Modules/Inputs/* Now that the module map file is handled by the main source manager, the VerifyDiagnosticConsumer will not ignore diagnostics created while parsing the module map file. The module test test/Modules/renamed.m uses -I test/Modules/Inputs and triggers recursive loading of all module maps in test/Modules/Inputs, some of which had conflicting names, thus leading errors while parsing the module maps. Those diagnostics already occur on trunk, but before this patch they would not break the test, as they were ignored by the VerifyDiagnosticConsumer. This patch thus changes the module maps that have been recently introduced which broke the invariant of compatible modules maps in test/Modules/Inputs. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@193314 91177308-0d34-0410-b5e6-96231b3b80d8
/external/clang/include/clang/Lex/ModuleMap.h
|
c641709607d45bf97772e925647db6c94866c50a |
|
22-Oct-2013 |
Daniel Jasper <djasper@google.com> |
Allow a header to be part of multiple modules. This patch changes two things: a) Allow a header to be part of multiple modules. The reasoning is that in existing codebases that have a module-like build system, the same headers might be used in several build targets. Simple reasons might be that they defined different classes that are declared in the same header. Supporting a header as a part of multiple modules will make the transistion easier for those cases. A later step in clang can then determine whether the two modules are actually compatible and can be merged and error out appropriately. The later check is similar to what needs to be done for template specializations anyway. b) Allow modules to be stored in a directory tree separate from the headers they describe. Review: http://llvm-reviews.chandlerc.com/D1951 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@193151 91177308-0d34-0410-b5e6-96231b3b80d8
/external/clang/include/clang/Lex/ModuleMap.h
|
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/include/clang/Lex/ModuleMap.h
|
8f5d7d1d1f990f174c7f2682271a83acf64dd93d |
|
21-Jun-2013 |
Douglas Gregor <dgregor@apple.com> |
[Modules] If a module map resides in a system header directory, treat it as a system module. This prevents -pedantic from causing warnings in the system headers used to create modules. Fixes <rdar://problem/14201171>. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@184560 91177308-0d34-0410-b5e6-96231b3b80d8
/external/clang/include/clang/Lex/ModuleMap.h
|
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/include/clang/Lex/ModuleMap.h
|
cdeba0b0127e0d97b10752a1e875901da4426810 |
|
20-Jun-2013 |
Lawrence Crowl <crowl@google.com> |
Fix English grammar error. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@184463 91177308-0d34-0410-b5e6-96231b3b80d8
/external/clang/include/clang/Lex/ModuleMap.h
|
7247c88d1e41514a41085f83ebf03dd5220e054a |
|
15-May-2013 |
David Blaikie <dblaikie@gmail.com> |
Use only explicit bool conversion operator The most common (non-buggy) case are where such objects are used as return expressions in bool-returning functions or as boolean function arguments. In those cases I've used (& added if necessary) a named function to provide the equivalent (or sometimes negative, depending on convenient wording) test. DiagnosticBuilder kept its implicit conversion operator owing to the prevalent use of it in return statements. One bug was found in ExprConstant.cpp involving a comparison of two PointerUnions (PointerUnion did not previously have an operator==, so instead both operands were converted to bool & then compared). A test is included in test/SemaCXX/constant-expression-cxx1y.cpp for the fix (adding operator== to PointerUnion in LLVM). git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@181869 91177308-0d34-0410-b5e6-96231b3b80d8
/external/clang/include/clang/Lex/ModuleMap.h
|
d3220dbeeadc4ac54ceecea8cf63f8d8be291d2a |
|
09-May-2013 |
Argyrios Kyrtzidis <akyrtzi@gmail.com> |
[modules] When building a module, make sure we don't serialize out HeaderFileInfo for headers not belonging to the module. After r180934 we may initiate module map parsing for modules not related to the module what we are building, make sure we ignore the header file info of headers from such modules. First part of rdar://13840148 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@181489 91177308-0d34-0410-b5e6-96231b3b80d8
/external/clang/include/clang/Lex/ModuleMap.h
|
a4a90cabfa15c900016a7cfaea51a6d4e8ebf4db |
|
04-May-2013 |
Douglas Gregor <dgregor@apple.com> |
When building a module, forward diagnostics to the outer diagnostic consumer. Previously, we would clone the current diagnostic consumer to produce a new diagnostic consumer to use when building a module. The problem here is that we end up losing diagnostics for important diagnostic consumers, such as serialized diagnostics (where we'd end up with two diagnostic consumers writing the same output file). With forwarding, the diagnostics from all of the different modules being built get forwarded to the one serialized-diagnostic consumer and are emitted in a sane way. Fixes <rdar://problem/13663996>. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@181067 91177308-0d34-0410-b5e6-96231b3b80d8
/external/clang/include/clang/Lex/ModuleMap.h
|
7332ae49671762239c9986c8f30f291c3a13d27e |
|
12-Apr-2013 |
Douglas Gregor <dgregor@apple.com> |
<rdar://problem/13643854> Only emit ambiguous-expansion warnings when at least one of the macro definitions comes from a non-system header. This slightly weakens the heuristic introduced in r178109. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@179411 91177308-0d34-0410-b5e6-96231b3b80d8
/external/clang/include/clang/Lex/ModuleMap.h
|
52151fd57eaf40603fa8f1cd34dcb4ad5f7701b3 |
|
27-Mar-2013 |
Argyrios Kyrtzidis <akyrtzi@gmail.com> |
[modules] Before marking the module imported macros as ambiguous, check if this is a case where the system macro uses a not identical definition compared to a macro from the clang headers. For example (these come from different modules): \#define LONG_MAX __LONG_MAX__ (clang's limits.h) \#define LONG_MAX 0x7fffffffffffffffL (system's limits.h) in which case don't mark them ambiguous to avoid the "ambiguous macro expansion" warning. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@178109 91177308-0d34-0410-b5e6-96231b3b80d8
/external/clang/include/clang/Lex/ModuleMap.h
|
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/include/clang/Lex/ModuleMap.h
|
55ea75bf61a5d76f6453513d937944ce68181c6a |
|
13-Mar-2013 |
Argyrios Kyrtzidis <akyrtzi@gmail.com> |
[Modules] Don't eagerly load and associate all the module header files. In a module-enabled Cocoa PCH file, we spend a lot of time stat'ing the headers in order to associate the FileEntries with their modules and support implicit module import. Use a more lazy scheme by enhancing HeaderInfoTable to store extra info about the module that a header belongs to, and associate it with its module only when there is a request for loading the header info for a particular file. Part of rdar://13391765 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@176976 91177308-0d34-0410-b5e6-96231b3b80d8
/external/clang/include/clang/Lex/ModuleMap.h
|
0be5e567e3a48592fd6b11f88cc77efb20c76f26 |
|
19-Feb-2013 |
Argyrios Kyrtzidis <akyrtzi@gmail.com> |
[modules] Const'ify some functions of ModuleMap. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@175552 91177308-0d34-0410-b5e6-96231b3b80d8
/external/clang/include/clang/Lex/ModuleMap.h
|
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/include/clang/Lex/ModuleMap.h
|
7005b907ea159c8e74e81f85269777429bc18d3c |
|
10-Jan-2013 |
Douglas Gregor <dgregor@apple.com> |
Rework the realpath nonsense for framework lookups to deal more uniformly with symlinks between top-level and embedded frameworks. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@172030 91177308-0d34-0410-b5e6-96231b3b80d8
/external/clang/include/clang/Lex/ModuleMap.h
|
30a2e16f6c27f888dd11eba6bbbae1e980078fcb |
|
04-Dec-2012 |
Chandler Carruth <chandlerc@gmail.com> |
Sort #include lines for all files under include/... This is a simpler sort, entirely automatic with the help of llvm/utils/sort_includes.py -- no manual edits here. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@169238 91177308-0d34-0410-b5e6-96231b3b80d8
/external/clang/include/clang/Lex/ModuleMap.h
|
82e52377bd76ed71e8c09edc5f2f452e388b16ad |
|
06-Nov-2012 |
Douglas Gregor <dgregor@apple.com> |
Introduce inferred framework modules into the module map file, allowing a module map to be placed one level above the '.framework' directories to specify that all .frameworks within that directory can be inferred as framework modules. One can also specifically exclude frameworks known not to work. This makes explicit (and more restricted) behavior modules have had "forever", where *any* .framework was assumed to be able to be built as a module. That's not necessarily true, so we white-list directories (with exclusions) when those directories have been audited. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@167482 91177308-0d34-0410-b5e6-96231b3b80d8
/external/clang/include/clang/Lex/ModuleMap.h
|
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/include/clang/Lex/ModuleMap.h
|
3d7e24e1887fade254cf8b304834f30de2f8d662 |
|
17-Jun-2012 |
James Dennett <jdennett@google.com> |
Documentation cleanup: add parameter name to \param git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@158633 91177308-0d34-0410-b5e6-96231b3b80d8
/external/clang/include/clang/Lex/ModuleMap.h
|
260328c27ddbad6e6d81a84e68a9a4aedccbfbf3 |
|
15-Jun-2012 |
James Dennett <jdennett@google.com> |
Documentation fix: Add a missing parameter name for a \param command git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@158512 91177308-0d34-0410-b5e6-96231b3b80d8
/external/clang/include/clang/Lex/ModuleMap.h
|
c93dc7889644293e318e19d82830ea2acc45b678 |
|
20-Feb-2012 |
Dylan Noblesmith <nobled@dreamwidth.org> |
Basic: import IntrusiveRefCntPtr<> into clang namespace The class name is long enough without the llvm:: added. Also bring in RefCountedBase and RefCountedBaseVPTR. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@150958 91177308-0d34-0410-b5e6-96231b3b80d8
/external/clang/include/clang/Lex/ModuleMap.h
|
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/include/clang/Lex/ModuleMap.h
|
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/include/clang/Lex/ModuleMap.h
|
c5b2e58840748145d1706c1d1481369d1863fabf |
|
29-Jan-2012 |
Douglas Gregor <dgregor@apple.com> |
Implement code completion support for module import declarations, e.g., @import <complete with module names here> or @import std.<complete with submodule names here> Addresses <rdar://problem/10710117>. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@149199 91177308-0d34-0410-b5e6-96231b3b80d8
/external/clang/include/clang/Lex/ModuleMap.h
|
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/include/clang/Lex/ModuleMap.h
|
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/include/clang/Lex/ModuleMap.h
|
77d029f6a24dbf70d97e61757945df53fb250ea0 |
|
08-Dec-2011 |
Douglas Gregor <dgregor@apple.com> |
Implement umbrella directories for modules, which are similar to umbrella headers in the sense that all of the headers within that directory (and eventually its subdirectories) are considered to be part of the module with that umbrella directory. However, unlike umbrella headers, which are expected to include all of the headers within their subdirectories, Clang will automatically include all of the headers it finds in the named subdirectory. The intent here is to allow a module map to trivially turn a subdirectory into a module, where the module's structure can mimic the directory structure. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@146165 91177308-0d34-0410-b5e6-96231b3b80d8
/external/clang/include/clang/Lex/ModuleMap.h
|
ac252a3b0f8101a7274309e4a5cf2d5f0fdba675 |
|
06-Dec-2011 |
Douglas Gregor <dgregor@apple.com> |
When inferring a module map for a framework, infer subframework modules for each of its subframeworks. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@145957 91177308-0d34-0410-b5e6-96231b3b80d8
/external/clang/include/clang/Lex/ModuleMap.h
|
e209e5026892cb07294f733c72bd51359c0f0e72 |
|
06-Dec-2011 |
Douglas Gregor <dgregor@apple.com> |
Implement inferred submodules support, which (when requested) implicitly generates submodules corresponding to the headers that fall within a module. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@145887 91177308-0d34-0410-b5e6-96231b3b80d8
/external/clang/include/clang/Lex/ModuleMap.h
|
55988680ece66b8e505ee136b35e74fcb1173aee |
|
05-Dec-2011 |
Douglas Gregor <dgregor@apple.com> |
When writing a module file, keep track of the set of (sub)modules that it imports, establishing dependencies at the (sub)module granularity. This is not a user-visible change (yet). git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@145808 91177308-0d34-0410-b5e6-96231b3b80d8
/external/clang/include/clang/Lex/ModuleMap.h
|
90db26000aefe9335370013eec64c85232d80227 |
|
02-Dec-2011 |
Douglas Gregor <dgregor@apple.com> |
Implementing parsing and resolution of module export declarations within module maps, which will (eventually) be used to re-export a module from another module. There are still some pieces missing, however. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@145665 91177308-0d34-0410-b5e6-96231b3b80d8
/external/clang/include/clang/Lex/ModuleMap.h
|
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/include/clang/Lex/ModuleMap.h
|
392ed2b717d86ebdd202cb9bb58d18d8b3b4cd87 |
|
30-Nov-2011 |
Douglas Gregor <dgregor@apple.com> |
Implement (de-)serialization of the description of a module and its submodules. This information will eventually be used for name hiding when dealing with submodules. For now, we only use it to ensure that the module "key" returned when loading a module will always be a module (rather than occasionally being a FileEntry). git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@145497 91177308-0d34-0410-b5e6-96231b3b80d8
/external/clang/include/clang/Lex/ModuleMap.h
|
f9e357d8a66c606a86a6e1aef678898b8843bd30 |
|
29-Nov-2011 |
Douglas Gregor <dgregor@apple.com> |
Teach the module import mechanism how to rebuild modules expressed via module map, rather than assuming that there is an umbrella header. This allows us to automatically build umbrella-less modules. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@145415 91177308-0d34-0410-b5e6-96231b3b80d8
/external/clang/include/clang/Lex/ModuleMap.h
|
804c3bfee22076f232dddf4839439119cfdee2b6 |
|
29-Nov-2011 |
Douglas Gregor <dgregor@apple.com> |
Expose the printing of module maps as part of the ModuleMap::Module interface. No functionality change. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@145411 91177308-0d34-0410-b5e6-96231b3b80d8
/external/clang/include/clang/Lex/ModuleMap.h
|
a865405e4155e8ea83d7ff1a1d8316907c300897 |
|
17-Nov-2011 |
Douglas Gregor <dgregor@apple.com> |
Add the notion of "framework" modules to module maps. Framework modules (obviously) describe frameworks, and understand the header layout of frameworks. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@144921 91177308-0d34-0410-b5e6-96231b3b80d8
/external/clang/include/clang/Lex/ModuleMap.h
|
09fe1bb696847e6f1b482e5ac40029d53a2402df |
|
17-Nov-2011 |
Douglas Gregor <dgregor@apple.com> |
Actually free memory for the module maps git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@144880 91177308-0d34-0410-b5e6-96231b3b80d8
/external/clang/include/clang/Lex/ModuleMap.h
|
2821c7f8870629b56b9c41e1c50c7a091edd544d |
|
17-Nov-2011 |
Douglas Gregor <dgregor@apple.com> |
When we're loading a framework header, first try to turn the framework into a module. This module can either be loaded from a module map in the framework directory (which isn't quite working yet) or inferred from an umbrella header (which does work, and replaces the existing hack). git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@144877 91177308-0d34-0410-b5e6-96231b3b80d8
/external/clang/include/clang/Lex/ModuleMap.h
|
adb979924ade3e25342c38a5b564400b4e0540c1 |
|
17-Nov-2011 |
Douglas Gregor <dgregor@apple.com> |
A module with an umbrella header assumes that all of the headers in the umbrella header's directory and its subdirectories are part of the module (that's why it's an umbrella). Make sure that these headers are considered to be part of the module for lookup purposes. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@144859 91177308-0d34-0410-b5e6-96231b3b80d8
/external/clang/include/clang/Lex/ModuleMap.h
|
484535e45b4d301847a157e943c7823da5d40884 |
|
12-Nov-2011 |
Douglas Gregor <dgregor@apple.com> |
Teach the search for modules to consider modules described by a module map, so long as they have an umbrella header. This makes it possible to introduce a module map + umbrella header for a given set of headers, to turn it into a module. There are two major deficiencies here: first, we don't go hunting for module map files when we just see a module import (so we won't know about the modules described therein). Second, we don't yet have a way to build modules that don't have umbrella headers, or have incomplete umbrella headers. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@144424 91177308-0d34-0410-b5e6-96231b3b80d8
/external/clang/include/clang/Lex/ModuleMap.h
|
65f3b5e99009f49d51eb00a859dbd2c2ee660718 |
|
11-Nov-2011 |
Douglas Gregor <dgregor@apple.com> |
Wire up the mapping from header files mentioned in module maps over to the corresponding (top-level) modules. This isn't actually useful yet, because we don't yet have a way to build modules out of module maps. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@144410 91177308-0d34-0410-b5e6-96231b3b80d8
/external/clang/include/clang/Lex/ModuleMap.h
|
a30cfe5026b12c28b7b575b48176e0a3543ce939 |
|
11-Nov-2011 |
Douglas Gregor <dgregor@apple.com> |
Introduce basic support for parsing module map files. Module map files provide a way to map between headers and modules, so that we can layer a module system on top of existing headers without changing those headers at all. This commit introduces the module map file parser and the module map that it generates, and wires up the module map file parser so that we'll automatically find module map files as part of header search. Note that we don't yet use the information stored in the module map. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@144402 91177308-0d34-0410-b5e6-96231b3b80d8
/external/clang/include/clang/Lex/ModuleMap.h
|