| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
| |
a system module.
This prevents -pedantic from causing warnings in the system headers
used to create modules. Fixes <rdar://problem/14201171>.
llvm-svn: 184560
|
|
|
|
|
|
|
| |
headers may be included from within the module, but not from outside
the module.
llvm-svn: 184471
|
|
|
|
|
|
| |
in system header directories.
llvm-svn: 181643
|
|
|
|
|
|
|
|
| |
This made sense in pre-module era, before merging of HeaderFileInfos was introduced.
Final part of rdar://13840148.
llvm-svn: 181490
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
of their subdirectory in the include path.
llvm-svn: 177621
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
| |
llvm-svn: 176535
|
|
|
|
| |
llvm-svn: 174683
|
|
|
|
| |
llvm-svn: 173578
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
from Saleem Abdulrasool!
llvm-svn: 173208
|
|
|
|
|
|
| |
brought into 'clang' namespace by clang/Basic/LLVM.h
llvm-svn: 172323
|
|
|
|
|
|
| |
uniformly with symlinks between top-level and embedded frameworks.
llvm-svn: 172030
|
|
|
|
|
|
| |
was #import'ed.
llvm-svn: 169761
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
reference-counted, and hold a reference to it in HeaderSearch.
llvm-svn: 166583
|
|
|
|
|
|
|
|
|
| |
top-level frameworks can actually be symlinked over to embedded
frameworks, and accessed via the top-level framework's headers. In
this case, we need to determine that the framework was *actually* an
embedded framework, so we can load the appropriate top-level module.
llvm-svn: 164620
|
|
|
|
|
|
| |
changes.
llvm-svn: 164103
|
|
|
|
|
|
|
|
|
|
|
| |
current directory, propagate the framework and in-index-header-map
from the including header's information down to the included header's
information. Fixes <rdar://problem/11261291>.
As with everything header-map related, we can't really test this in
isolation within Clang, so it's tested elsewhere.
llvm-svn: 161759
|
|
|
|
| |
llvm-svn: 160622
|
|
|
|
|
|
|
|
| |
* Escaped # and < characters in Doxygen comments as needed;
* Removed a Doxygen comment in HeaderSearch.cpp that was redundant with
the corresponding comment in the header file.
llvm-svn: 158776
|
|
|
|
| |
llvm-svn: 158420
|
|
|
|
|
|
|
|
|
|
| |
override whether headers are system headers by checking for prefixes of the
header name specified in the #include directive.
This allows warnings to be disabled for third-party code which is found in
specific subdirectories of include paths.
llvm-svn: 158418
|
|
|
|
|
|
| |
- Developers of system frameworks need a way for their framework to be treated as a "system framework" during development. Otherwise, they are unable to properly test how their framework behaves when installed because of the semantic changes (in warning behavior) applied to system frameworks.
llvm-svn: 154105
|
|
|
|
|
|
|
|
| |
FrameworkMap items.
- No functionality change.
llvm-svn: 154104
|
|
|
|
| |
llvm-svn: 154103
|
|
|
|
|
|
|
| |
(I was going to fix the TODO about DenseMap too, but
that would break self-host right now. See PR11922.)
llvm-svn: 149799
|
|
|
|
|
|
| |
target-specific module requirements.
llvm-svn: 149224
|
|
|
|
|
|
|
|
|
|
|
|
| |
@import <complete with module names here>
or
@import std.<complete with submodule names here>
Addresses <rdar://problem/10710117>.
llvm-svn: 149199
|
|
|
|
|
|
|
|
|
| |
for getting the name of the module file, unifying the code for
searching for a module with a given name (into lookupModule()) and
separating out the mapping to a module file (into
getModuleFileName()). No functionality change.
llvm-svn: 149197
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
appropriate or when GCC requires it)
llvm-svn: 148292
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
framework is actually a subframework within a top-level framework. If
so, only infer a module for the top-level framework and then dig out
the appropriate submodule.
This helps us cope with an amusing subframeworks anti-pattern, where
one uses -F <framework>/Frameworks to get direct include access to the
subframeworks of a framework (which otherwise would not be
permitted).
llvm-svn: 148148
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
| |
".framework/" in the path name, because it could be ".framework\" on
Windows. This whole function needs to be rewritten with PathV2.
llvm-svn: 146261
|
|
|
|
|
|
|
|
| |
part of HeaderSearch. This function just normalizes filenames for use
inside of a synthetic include directive, but it is used in both the
Frontend and Serialization libraries so it needs a common home.
llvm-svn: 146227
|
|
|
|
|
|
|
| |
that's currently being built. This is important for supporting
transitive dependencies ("export *" in the module map) completely.
llvm-svn: 146156
|
|
|
|
| |
llvm-svn: 146074
|
|
|
|
|
|
|
|
|
| |
when we load a module map (module.map) from a directory, also load a
private module map (module_private.map) for that directory, if
present. That private module map can inject a new submodule that
captures private headers.
llvm-svn: 146012
|
|
|
|
|
|
| |
modules for each of its subframeworks.
llvm-svn: 145957
|
|
|
|
|
|
|
|
| |
most specific (sub)module based on the actual file we find, rather
than always importing the top-level module. This means
that #include'ing <Foo/Blah.h> should give us the submodule Foo.Blah.
llvm-svn: 145942
|
|
|
|
|
|
|
|
|
| |
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).
llvm-svn: 145538
|
|
|
|
|
|
|
|
| |
return the module itself (in the module map) rather than returning the
umbrella header used to build the module. While doing this, make sure
that we're inferring modules for frameworks to build that module.
llvm-svn: 145310
|
|
|
|
|
|
| |
from Jason Haslam!
llvm-svn: 145012
|
|
|
|
|
|
|
| |
preprocess/parse a header, report back with an actual module (which
may be a submodule) rather than just the name of the module.
llvm-svn: 144925
|
|
|
|
|
|
|
|
|
| |
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).
llvm-svn: 144877
|
|
|
|
|
|
|
| |
interface. This is currently limited to modules with umbrella
headers.
llvm-svn: 144736
|
|
|
|
|
|
|
|
| |
module import: don't re-check for a loaded module unless we've
actually loaded a new module map file. Already-loaded module map files
aren't interesting.
llvm-svn: 144435
|