Reinstate r223753, reverted in r223759 due to breakage of clang-tools-extra.
Original commit message:

[modules] Add experimental -fmodule-map-file-home-is-cwd flag to -cc1.

For files named by -fmod

Reinstate r223753, reverted in r223759 due to breakage of clang-tools-extra.
Original commit message:

[modules] Add experimental -fmodule-map-file-home-is-cwd flag to -cc1.

For files named by -fmodule-map-file=, and files found by 'extern module'
directives, this flag specifies that we should resolve filenames relative to
the current working directory rather than relative to the directory in which
the module map file resides. This is aimed at fixing path handling, in
particular for relative -I paths, when building modules that represent
components of the current project (rather than libraries installed on the
current system, which the current project has as dependencies, where we'd
typically expect the module map files to be looked up implicitly).

llvm-svn: 223913

show more ...

Revert "[modules] Add experimental -fmodule-map-file-home-is-cwd flag to -cc1."

This reverts commit r223753. It broke the Green Dragon build for a few
hours:

http://lab.llvm.org:8080/green/job/c

Revert "[modules] Add experimental -fmodule-map-file-home-is-cwd flag to -cc1."

This reverts commit r223753. It broke the Green Dragon build for a few
hours:

http://lab.llvm.org:8080/green/job/clang-stage1-cmake-RA-incremental_build/2259/
http://lab.llvm.org:8080/green/job/clang-stage1-cmake-RA-incremental_build/2259/consoleFull#43901905849ba4694-19c4-4d7e-bec5-911270d8a58c

I suspect `clang-tools-extra` just needs a follow-up for an API change,
but I'm not the right one to look into it.

llvm-svn: 223759

show more ...

[modules] Add experimental -fmodule-map-file-home-is-cwd flag to -cc1.

For files named by -fmodule-map-file=, and files found by 'extern module'
directives, this flag specifies that we should resolv

[modules] Add experimental -fmodule-map-file-home-is-cwd flag to -cc1.

For files named by -fmodule-map-file=, and files found by 'extern module'
directives, this flag specifies that we should resolve filenames relative to
the current working directory rather than relative to the directory in which
the module map file resides. This is aimed at fixing path handling, in
particular for relative -I paths, when building modules that represent
components of the current project (rather than libraries installed on the
current system, which the current project has as dependencies, where we'd
typically expect the module map files to be looked up implicitly).

llvm-svn: 223753

show more ...

Try to fix the MSVC build.

llvm-svn: 223105

[modules] Track how 'header' directives were written in module map files,
rather than trying to extract this information from the FileEntry after the
fact.

This has a number of beneficial effects. F

[modules] Track how 'header' directives were written in module map files,
rather than trying to extract this information from the FileEntry after the
fact.

This has a number of beneficial effects. For instance, diagnostic messages for
failed module builds give a path relative to the "module root" rather than an
absolute file path, and the contents of the module includes file is no longer
dependent on what files the including TU happened to inspect prior to
triggering the module build.

llvm-svn: 223095

show more ...

ModuleMap.cpp: fix Windows build, take 2

llvm-svn: 220646

ModuleMap.cpp: fix VS2012 build

llvm-svn: 220644

ModuleMap::addHeader(): Appease msc17.

llvm-svn: 220639

[modules] Support combining 'textual' with 'private'.

llvm-svn: 220589

Refactor implementation of 'exclude header'.

This was not a real header role, and was never exposed to clients of ModuleMap.
Remove the enumeration value for it and track it as marking the header as

Refactor implementation of 'exclude header'.

This was not a real header role, and was never exposed to clients of ModuleMap.
Remove the enumeration value for it and track it as marking the header as
'known' rather than creating an extra KnownHeader entry that *every single*
client ignores.

llvm-svn: 220460

show more ...

Fix covered-switch warning.

llvm-svn: 220456

[modules] Add support for 'textual header' directives.

This allows a module to specify that it logically contains a file, but that
said file is non-modular and intended for textual inclusion. This a

[modules] Add support for 'textual header' directives.

This allows a module to specify that it logically contains a file, but that
said file is non-modular and intended for textual inclusion. This allows
layering checks to work properly in the presence of such files.

llvm-svn: 220448

show more ...

[modules] Add support for #include_next.

#include_next interacts poorly with modules: it depends on where in the list of
include paths the current file was found. Files covered by module maps are no

[modules] Add support for #include_next.

#include_next interacts poorly with modules: it depends on where in the list of
include paths the current file was found. Files covered by module maps are not
found in include search paths when building the module (and are not found in
include search paths when @importing the module either), so this isn't really
meaningful. Instead, we fake up the result that #include_next *should* have
given: find the first path that would have resulted in the given file being
picked, and search from there onwards.

llvm-svn: 220177

show more ...

Verify all the module map files for a pcm are the same on load

We already verified the primary module map file (either the one that
defines the top-level module, or the one that allows inferring it

Verify all the module map files for a pcm are the same on load

We already verified the primary module map file (either the one that
defines the top-level module, or the one that allows inferring it if it
is an inferred framework module). Now we also verify any other module
map files that define submodules, such as when there is a
module.private.modulemap file.

llvm-svn: 215455

show more ...

Refactor the module map file used for uniquing a module name out of

class Module. It's almost always going to be the same as
getContainingModule() for top-level modules, so just add a map to cover
t

Refactor the module map file used for uniquing a module name out of

class Module. It's almost always going to be the same as
getContainingModule() for top-level modules, so just add a map to cover
the remaining cases. This lets us do less bookkeeping to keep the
ModuleMap fields up to date.

llvm-svn: 215268

show more ...

Fix case-sensitivity of inferred framework modules

Just because we can open a directory named "COcoa.framework" doesn't
mean we should provide a "COcoa" module on a case-insensitive filesystem.

llv

Fix case-sensitivity of inferred framework modules

Just because we can open a directory named "COcoa.framework" doesn't
mean we should provide a "COcoa" module on a case-insensitive filesystem.

llvm-svn: 212975

show more ...

Convert StringLiteralParser constructor to use ArrayRef instead of a pointer and count.

llvm-svn: 211763

Replace llvm::error_code with std::error_code.

llvm-svn: 210780

[C++11] Use 'nullptr'. Lex edition.

llvm-svn: 209083

Provide and use a safe Token::getRawIdentifier() accessor

llvm-svn: 209061

Remove -Wnon-modular-include

But keep -Wnon-modular-include-in-[framework-]module

This warning is too noisy and doesn't really indicate a problem for most
people. Even though it would only really

Remove -Wnon-modular-include

But keep -Wnon-modular-include-in-[framework-]module

This warning is too noisy and doesn't really indicate a problem for most
people. Even though it would only really affect people using
-Weverything, that seems bad so remove it.

llvm-svn: 208345

show more ...

Add -Wnon-modular-include* options

Warn on non-modular includes in various contexts.

-Wnon-modular-include
-Wnon-modular-include-in-module
-Wnon-modular-include-in-framework-module

Where each g

Add -Wnon-modular-include* options

Warn on non-modular includes in various contexts.

-Wnon-modular-include
-Wnon-modular-include-in-module
-Wnon-modular-include-in-framework-module

Where each group is a subgroup of those above it.

llvm-svn: 208004

show more ...

Do not print inferred submodules explicitly in __inferred_module.map

Otherwise including a header in your source file that is not included by
framework's umbrella header will silently add an empty s

Do not print inferred submodules explicitly in __inferred_module.map

Otherwise including a header in your source file that is not included by
framework's umbrella header will silently add an empty submodule with that
name.

is automatically translated to
@import Foo.NotInModule;

which then would have succeeded because the inferred module map
contained an empty submodule called NotInModule.

llvm-svn: 207024

show more ...

Allow submodule inferrences with a missing umbrella when the module is unavailable

If the module is unavailable because of a missing header, don't diagnose
a "module * {}" declaration for having a m

Allow submodule inferrences with a missing umbrella when the module is unavailable

If the module is unavailable because of a missing header, don't diagnose
a "module * {}" declaration for having a missing umbrella.

llvm-svn: 206776

show more ...

Don't build modules with (submodules with) missing headers

Unless they are in submodules that aren't available anyway, due to
requirements not being met. Also, mark children as unavailable when the

Don't build modules with (submodules with) missing headers

Unless they are in submodules that aren't available anyway, due to
requirements not being met. Also, mark children as unavailable when the
parent is.

llvm-svn: 206664

show more ...