(I was going to fix the TODO about DenseMap too, but
that would break self-host right now. See PR11922.)
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@149799 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@149197 91177308-0d34-0410-b5e6-96231b3b80d8
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
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).
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@148148 91177308-0d34-0410-b5e6-96231b3b80d8
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
".framework/" in the path name, because it could be ".framework\" on
Windows. This whole function needs to be rewritten with PathV2.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@146261 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@146227 91177308-0d34-0410-b5e6-96231b3b80d8
that's currently being built. This is important for supporting
transitive dependencies ("export *" in the module map) completely.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@146156 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@146012 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@145942 91177308-0d34-0410-b5e6-96231b3b80d8
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
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@145310 91177308-0d34-0410-b5e6-96231b3b80d8
preprocess/parse a header, report back with an actual module (which
may be a submodule) rather than just the name of the module.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@144925 91177308-0d34-0410-b5e6-96231b3b80d8
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
the module is described in one of the module maps in a search path or
in a subdirectory off the search path that has the same name as the
module we're looking for.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@144433 91177308-0d34-0410-b5e6-96231b3b80d8
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
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
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
the AST reader), merge that header file information with whatever
header file information we already have. Otherwise, we might forget
something we already knew (e.g., that the header was #import'd already).
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@139979 91177308-0d34-0410-b5e6-96231b3b80d8
#include or #import direcctives of framework headers into module
imports of the corresponding framework module.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@139860 91177308-0d34-0410-b5e6-96231b3b80d8
target triple to separate modules built under different
conditions. The hash is used to create a subdirectory in the module
cache path where other invocations of the compiler (with the same
version, language options, etc.) can find the precompiled modules.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@139662 91177308-0d34-0410-b5e6-96231b3b80d8
but there is a corresponding umbrella header in a framework, build the
module on-the-fly so it can be immediately loaded at the import
statement. This is very much proof-of-concept code, with details to be
fleshed out over time.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@139558 91177308-0d34-0410-b5e6-96231b3b80d8
where the compiler will look for module files. Eliminates the
egregious hack where we looked into the header search paths for
modules.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@139538 91177308-0d34-0410-b5e6-96231b3b80d8
for quoted header lookup when dealing with not-yet-installed
frameworks. Fixes <rdar://problem/9824020>.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@136331 91177308-0d34-0410-b5e6-96231b3b80d8
This required converting the StringMaps to use a BumpPtrAllocator. I measured the
compile time and saw no observable regression.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@136190 91177308-0d34-0410-b5e6-96231b3b80d8
which determines whether a particular file is actually a header that
is intended to be guarded from multiple inclusions within the same
translation unit.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@130808 91177308-0d34-0410-b5e6-96231b3b80d8
includes get resolved, especially when they are found relatively to
another include file. We also try to get it working for framework
includes, but that part of the code is untested, as I don't have a code
base that uses it.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@130246 91177308-0d34-0410-b5e6-96231b3b80d8
Add 'openFile' bool to FileManager::getFile to specify whether we want to have the file opened or not, have it
false by default, and enable it only in HeaderSearch.cpp where the open+fstat optimization matters.
Fixes rdar://9139899.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@127748 91177308-0d34-0410-b5e6-96231b3b80d8
clients to observe the exact path through which an #included file was
located. This is very useful when trying to record and replay inclusion
operations without it beind influenced by the aggressive caching done
inside the FileManager to avoid redundant system calls and filesystem
operations.
The work to compute and return this is only done in the presence of
callbacks, so it should have no effect on normal compilation.
Patch by Manuel Klimek.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@127742 91177308-0d34-0410-b5e6-96231b3b80d8
AST/PCH files more lazy:
- Don't preload all of the file source-location entries when reading
the AST file. Instead, load them lazily, when needed.
- Only look up header-search information (whether a header was already
#import'd, how many times it's been included, etc.) when it's needed
by the preprocessor, rather than pre-populating it.
Previously, we would pre-load all of the file source-location entries,
which also populated the header-search information structure. This was
a relatively minor performance issue, since we would end up stat()'ing
all of the headers stored within a AST/PCH file when the AST/PCH file
was loaded. In the normal PCH use case, the stat()s were cached, so
the cost--of preloading ~860 source-location entries in the Cocoa.h
case---was relatively low.
However, the recent optimization that replaced stat+open with
open+fstat turned this into a major problem, since the preloading of
source-location entries would now end up opening those files. Worse,
those files wouldn't be closed until the file manager was destroyed,
so just opening a Cocoa.h PCH file would hold on to ~860 file
descriptors, and it was easy to blow through the process's limit on
the number of open file descriptors.
By eliminating the preloading of these files, we neither open nor stat
the headers stored in the PCH/AST file until they're actually needed
for something. Concretely, we went from
*** HeaderSearch Stats:
835 files tracked.
364 #import/#pragma once files.
823 included exactly once.
6 max times a file is included.
3 #include/#include_next/#import.
0 #includes skipped due to the multi-include optimization.
1 framework lookups.
0 subframework lookups.
*** Source Manager Stats:
835 files mapped, 3 mem buffers mapped.
37460 SLocEntry's allocated, 11215575B of Sloc address space used.
62 bytes of files mapped, 0 files with line #'s computed.
with a trivial program that uses a chained PCH including a Cocoa PCH
to
*** HeaderSearch Stats:
4 files tracked.
1 #import/#pragma once files.
3 included exactly once.
2 max times a file is included.
3 #include/#include_next/#import.
0 #includes skipped due to the multi-include optimization.
1 framework lookups.
0 subframework lookups.
*** Source Manager Stats:
3 files mapped, 3 mem buffers mapped.
37460 SLocEntry's allocated, 11215575B of Sloc address space used.
62 bytes of files mapped, 0 files with line #'s computed.
for the same program.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@125286 91177308-0d34-0410-b5e6-96231b3b80d8
FileSystemOpts through a ton of apis, simplifying a lot of code.
This also fixes a latent bug in ASTUnit where it would invoke
methods on FileManager without creating one in some code paths
in cindextext.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@120010 91177308-0d34-0410-b5e6-96231b3b80d8
When -working-directory is passed in command line, file paths are resolved relative to the specified directory.
This helps both when using libclang (where we can't require the user to actually change the working directory)
and to help reproduce test cases when the reproduction work comes along.
--FileSystemOptions is introduced which controls how file system operations are performed (currently it just contains
the working directory value if set).
--FileSystemOptions are passed around to various interfaces that perform file operations.
--Opening & reading the content of files should be done only through FileManager. This is useful in general since
file operations will be abstracted in the future for the reproduction mechanism.
FileSystemOptions is independent of FileManager so that we can have multiple translation units sharing the same
FileManager but with different FileSystemOptions.
Addresses rdar://8583824.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@118203 91177308-0d34-0410-b5e6-96231b3b80d8
PCH file. In the Cocoa-prefixed "Hello, World" benchmark, this takes
us from reading 503 identifiers down to 37 and from 470 macros down to
4. It also results in an 8% performance improvement.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@70094 91177308-0d34-0410-b5e6-96231b3b80d8
lib dir and move all the libraries into it. This follows the main
llvm tree, and allows the libraries to be built in parallel. The
top level now enforces that all the libs are built before Driver,
but we don't care what order the libs are built in. This speeds
up parallel builds, particularly incremental ones.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@48402 91177308-0d34-0410-b5e6-96231b3b80d8
Dylan Noblesmith