summaryrefslogtreecommitdiffstats
path: root/clang/lib/Lex/ModuleMap.cpp
Commit message (Collapse)AuthorAgeFilesLines
...
* [Modules] Make r180934 more efficient by only loading top-level module maps ↵Douglas Gregor2013-05-101-2/+1
| | | | | | in system header directories. llvm-svn: 181643
* [modules] When building a module, make sure we don't serialize out ↵Argyrios Kyrtzidis2013-05-081-3/+9
| | | | | | | | | | | 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 llvm-svn: 181489
* When building a module, forward diagnostics to the outer diagnostic consumer.Douglas Gregor2013-05-031-2/+3
| | | | | | | | | | | | | | | 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>. llvm-svn: 181067
* When looking for the module associated with one of our magical builtin ↵Douglas Gregor2013-05-021-18/+37
| | | | | | | | | | | | | | | headers, speculatively load module maps. The "magical" builtin headers are the headers we provide as part of the C standard library, which typically comes from /usr/include. We essentially merge our headers into that location (due to cyclic dependencies). This change makes sure that, when header search finds one of our builtin headers, we figure out which module it actually lives in. This case is fairly rare; one ends up having to include one of the few built-in C headers we provide before including anything from /usr/include to trigger it. Fixes <rdar://problem/13787184>. llvm-svn: 180934
* <rdar://problem/12368093> Extend module maps with a 'conflict' declaration, ↵Douglas Gregor2013-03-201-18/+102
| | | | | | and warn when a newly-imported module conflicts with an already-imported module. llvm-svn: 177577
* <rdar://problem/10796651> Introduce configuration macros into module maps.Douglas Gregor2013-03-201-4/+75
| | | | | | | | | | | | | | | | | | | | | | 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] Don't eagerly load and associate all the module header files.Argyrios Kyrtzidis2013-03-131-4/+9
| | | | | | | | | | | | | | 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 llvm-svn: 176976
* [Modules] Resolve top-headers of modules lazily.Argyrios Kyrtzidis2013-03-131-1/+1
| | | | | | | | | | | 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] Const'ify some functions of ModuleMap.Argyrios Kyrtzidis2013-02-191-12/+13
| | | | llvm-svn: 175552
* Excise <cctype> from Clang (except clang-tblgen) in favor of CharInfo.h.Jordan Rose2013-02-081-14/+4
| | | | | | | Nearly all of these changes are one-to-one replacements; the few that aren't have to do with custom identifier validation. llvm-svn: 174768
* <limits.h> includes <linux/limits.h> on Linux, no need to special-case itDmitri Gribenko2013-01-261-3/+1
| | | | llvm-svn: 173578
* Since we're stuck with realpath for the header <-> module mapping,Douglas Gregor2013-01-261-38/+21
| | | | | | | | factor the realpath calls into FileManager::getCanonicalName() so we can cache the results of this epically slow operation. 5% speedup on my modules test, and realpath drops out of the profile. llvm-svn: 173542
* Fix compilation on Linux, which defines PATH_MAX in a weird place,Douglas Gregor2013-01-221-0/+5
| | | | | | from Saleem Abdulrasool! llvm-svn: 173208
* Infer "link" lines for top-level frameworks. Essentially, a frameworkDouglas Gregor2013-01-141-0/+30
| | | | | | | | will have a shared library with the same name as its framework (and no suffix!) within its .framework directory. Detect this both when inferring the whole top-level framework and when parsing a module map. llvm-svn: 172439
* Implement parsing, AST, (de-)serialization, and placeholder globalDouglas Gregor2013-01-141-3/+41
| | | | | | | | | | | | | | | | | | | | | | | | | 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/+5
| | | | | | brought into 'clang' namespace by clang/Basic/LLVM.h llvm-svn: 172323
* Rework the realpath nonsense for framework lookups to deal moreDouglas Gregor2013-01-101-5/+22
| | | | | | uniformly with symlinks between top-level and embedded frameworks. llvm-svn: 172030
* realpath'ify the mapping from header includes to module imports.Douglas Gregor2013-01-041-0/+13
| | | | llvm-svn: 171516
* Revert r170500. It over-zealously converted *ALL* things named Attributes, ↵Bill Wendling2012-12-201-6/+6
| | | | | | which is wrong here. llvm-svn: 170721
* Rename the 'Attributes' class to 'Attribute'. It's going to represent a ↵Bill Wendling2012-12-191-6/+6
| | | | | | single attribute in the future. llvm-svn: 170500
* Sort all of Clang's files under 'lib', and fix up the broken headersChandler Carruth2012-12-041-5/+5
| | | | | | | | | | | | | 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. llvm-svn: 169237
* If an excluded header does not exist, just ignore itDouglas Gregor2012-11-151-1/+3
| | | | llvm-svn: 168077
* Remove C++11-isms I just introduced in r167482Douglas Gregor2012-11-061-3/+3
| | | | llvm-svn: 167483
* Introduce inferred framework modules into the module map file,Douglas Gregor2012-11-061-84/+236
| | | | | | | | | | | | | | 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. llvm-svn: 167482
* Make DiagnosticOptions intrusively reference-counted, and make sureDouglas Gregor2012-10-231-1/+2
| | | | | | | the various stakeholders bump up the reference count. In particular, the diagnostics engine now keeps the DiagnosticOptions object alive. llvm-svn: 166508
* Teach TargetInfo to hold on to the TargetOptions with which it wasDouglas Gregor2012-10-151-11/+9
| | | | | | created. llvm-svn: 165943
* Introduce the notion of excluded headers into the module mapDouglas Gregor2012-10-151-30/+46
| | | | | | | | 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. llvm-svn: 165921
* Sanitize the names of modules determined based on the names of headersDouglas Gregor2012-10-121-6/+67
| | | | | | | or directories, to make sure that they are identifiers that are not keywords in any dialect. Fixes <rdar://problem/12489495>. llvm-svn: 165821
* [Modules] Introduce Module::TopHeaders which is a set of top-level headersArgyrios Kyrtzidis2012-10-051-0/+1
| | | | | | that are associated with a (sub)module. llvm-svn: 165279
* Following up on r164620, cope with symlinking from an embeddedDouglas Gregor2012-09-271-1/+30
| | | | | | | framework location out to a top-level framework. Such frameworks are not really embedded at all. llvm-svn: 164774
* Make ModuleMapParser own its TargetInfo, so it doesn't get leaked.Benjamin Kramer2012-03-291-2/+2
| | | | llvm-svn: 153648
* User-defined literals: reject string and character UDLs in all places where theRichard Smith2012-03-061-0/+6
| | | | | | | | | | grammar requires a string-literal and not a user-defined-string-literal. The two constructs are still represented by the same TokenKind, in order to prevent a combinatorial explosion of different kinds of token. A flag on Token tracks whether a ud-suffix is present, in order to prevent clients from needing to look at the token's spelling. llvm-svn: 152098
* Basic: import IntrusiveRefCntPtr<> into clang namespaceDylan Noblesmith2012-02-201-2/+2
| | | | | | | The class name is long enough without the llvm:: added. Also bring in RefCountedBase and RefCountedBaseVPTR. llvm-svn: 150958
* Move instantiateTemplateAttribute into the sema namespace, make helpers static.Benjamin Kramer2012-02-061-1/+2
| | | | llvm-svn: 149864
* Basic: import SmallString<> into clang namespaceDylan Noblesmith2012-02-051-6/+6
| | | | | | | (I was going to fix the TODO about DenseMap too, but that would break self-host right now. See PR11922.) llvm-svn: 149799
* Back out my heinous hack that tricked the module generation mechanismDouglas Gregor2012-02-021-5/+52
| | | | | | | | | | | | | | | | | | | | 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. llvm-svn: 149611
* Thread a TargetInfo through to the module map; we'll need it forDouglas Gregor2012-01-301-3/+10
| | | | | | target-specific module requirements. llvm-svn: 149224
* Introduce module attributes into the module map grammar, along with aDouglas Gregor2012-01-271-7/+101
| | | | | | | | | | | | | 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. llvm-svn: 149143
* Remove unreachable code in Clang. (replace with llvm_unreachable where ↵David Blaikie2012-01-171-2/+0
| | | | | | appropriate or when GCC requires it) llvm-svn: 148292
* Don't infer a submodule for a framework's private header, at least for now.Douglas Gregor2012-01-131-14/+1
| | | | llvm-svn: 148117
* Revert previous commit. Something has gone wonky with my local configurationDouglas Gregor2012-01-131-1/+0
| | | | llvm-svn: 148084
* When inferring a module map for a framework, add the 'private'Douglas Gregor2012-01-131-0/+1
| | | | | | | requirement to headers under PrivateHeaders. We don't want to build them as part of the module (yet). llvm-svn: 148082
* When inferring a submodule ID during module creation, look up theDouglas Gregor2012-01-061-5/+16
| | | | | | | | | | include stack to find the first file that is known to be part of the module. This copes with situations where the module map doesn't completely specify all of the headers that are involved in the module, which can come up when there are very strange #include_next chains (e.g., with weird compiler/stdlib headers like stdarg.h or float.h). llvm-svn: 147662
* If we already have a definition for a top-level module that we deserialized ↵Douglas Gregor2012-01-051-0/+13
| | | | | | from a module file, don't bother parsing a new definition llvm-svn: 147574
* Store the submodules of a module in source order, as they are storedDouglas Gregor2012-01-041-25/+11
| | | | | | | | 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. llvm-svn: 147564
* Implement support for module requirements, which indicate the languageDouglas Gregor2011-12-311-6/+134
| | | | | | | | | 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). llvm-svn: 147387
* Set umbrella directory correctly when we infer a framework moduleDouglas Gregor2011-12-121-1/+1
| | | | llvm-svn: 146451
* Implement the notion of umbrella directories, which implicity coverDouglas Gregor2011-12-091-67/+33
| | | | | | | | | | | | | all of the headers below that particular directory. Use umbrella directories as a clean way to deal with (1) directories/frameworks that don't have an umbrella header, but don't want to enumerate all of their headers, and (2) PrivateHeaders, which we never want to enumerate and want to keep separate from the main umbrella header. This also eliminates a little more of the "magic" for private headers, and frameworks in general. llvm-svn: 146235
* Implement umbrella directories for modules, which are similar toDouglas Gregor2011-12-081-10/+73
| | | | | | | | | | | | | | | 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. llvm-svn: 146165
* Tweak the syntax of umbrella headers, so that "umbrella" is treated asDouglas Gregor2011-12-081-101/+36
| | | | | | | | | | | 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. llvm-svn: 146159
OpenPOWER on IntegriCloud