Use the multiple argument form of path::append.

llvm-svn: 185164

[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:/

[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>.

llvm-svn: 184560

show more ...

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.

llvm-svn: 184471

Include Path.h instead of PathV2.h.

I am about to move PathV2.h to Path.h.

llvm-svn: 183795

[Modules] Make r180934 more efficient by only loading top-level module maps in system header directories.

llvm-svn: 181643

[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

[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

llvm-svn: 181489

show more ...

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 m

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>.

llvm-svn: 181067

show more ...

When looking for the module associated with one of our magical builtin headers, speculatively load module maps.

The "magical" builtin headers are the headers we provide as part of
the C standard lib

When looking for the module associated with one of our magical builtin 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

show more ...

<rdar://problem/12368093> Extend module maps with a 'conflict' declaration, 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.

Configuration macros are macros that are intended to alter how a
module works, such that we need to build different module

<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).

llvm-svn: 177466

show more ...

[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 the

[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

llvm-svn: 176976

show more ...

[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 fun

[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.

llvm-svn: 176975

show more ...

[modules] Const'ify some functions of ModuleMap.

llvm-svn: 175552

Excise <cctype> from Clang (except clang-tblgen) in favor of CharInfo.h.

Nearly all of these changes are one-to-one replacements; the few that
aren't have to do with custom identifier validation.

l

Excise <cctype> from Clang (except clang-tblgen) in favor of CharInfo.h.

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

show more ...

<limits.h> includes <linux/limits.h> on Linux, no need to special-case it

llvm-svn: 173578

Since we're stuck with realpath for the header <-> module mapping,
factor the realpath calls into FileManager::getCanonicalName() so we
can cache the results of this epically slow operation. 5% speed

Since we're stuck with realpath for the header <-> module mapping,
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

show more ...

Fix compilation on Linux, which defines PATH_MAX in a weird place,
from Saleem Abdulrasool!

llvm-svn: 173208

Infer "link" lines for top-level frameworks. Essentially, a framework
will have a shared library with the same name as its framework (and no
suffix!) within its .framework directory. Detect this both

Infer "link" lines for top-level frameworks. Essentially, a framework
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

show more ...

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" d

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.

llvm-svn: 172437

show more ...

Remove useless 'llvm::' qualifier from names like StringRef and others that are
brought into 'clang' namespace by clang/Basic/LLVM.h

llvm-svn: 172323

Rework the realpath nonsense for framework lookups to deal more
uniformly with symlinks between top-level and embedded frameworks.

llvm-svn: 172030

realpath'ify the mapping from header includes to module imports.

llvm-svn: 171516

Revert r170500. It over-zealously converted *ALL* things named Attributes, which is wrong here.

llvm-svn: 170721

Rename the 'Attributes' class to 'Attribute'. It's going to represent a single attribute in the future.

llvm-svn: 170500

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/util

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.

llvm-svn: 169237

show more ...