(1) Collect headers under inner frameworks (frameworks inside other
other frameworks).
(2) Make sure we also collect the right header files inside them.

More info on (2):

Consider a dummy framework module B, with header Frameworks/B/B.h. Now
consider that another framework A, with header Frameworks/A/A.h, has a
layout with a inner framework Frameworks/A/Frameworks/B/B.h, where the
"B/B.h" part is a symlink for Frameworks/B/B.h. Also assume that
Frameworks/A/A.h includes <B/B.h>.

When parsing header Frameworks/A/A.h, framework module lookup is
performed in search for B, and it happens that
"Frameworks/A/Frameworks/B/B.h" path is registered in the module instead
of real "Frameworks/B/B.h". This occurs because
"Frameworks/A/Frameworks/B/B.h" is scanned first by the FileManager,
when looking for inner framework modules under Frameworks/A/Frameworks.
This makes Frameworks/A/Frameworks/B/B.h the default cached named inside
the FileManager for the B.h file UID.

This leads to modules being built without consistent paths to underlying
header files. This is usually not a problem in regular compilation flow,
but it's an issue when running the crash reproducer. The issue is that
clangs collect "Frameworks/A/Frameworks/B/B.h" but not
"Frameworks/B/B.h" into the VFS, leading to err_mmap_umbrella_clash. So
make sure we also collect the original header.

Differential Revision: http://reviews.llvm.org/D20194

rdar://problem/25880368

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@269502 91177308-0d34-0410-b5e6-96231b3b80d8

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@268843 91177308-0d34-0410-b5e6-96231b3b80d8

Use a StringRef instead of a FileEntry in the moduleMapAddHeader
callback to allow more flexibility on what to collect on further
patches. This changes the interface I introduced in r264971.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@268819 91177308-0d34-0410-b5e6-96231b3b80d8

the current language doesn't have an import syntax and we can figure out a
suitable file to include.


git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@267802 91177308-0d34-0410-b5e6-96231b3b80d8

The current ModuleDependencyCollector has a AST listener to collect
header files present in loaded modules, but this isn't enough to collect
all headers needed in the crash reproducer. One of the reasons is that
the AST writer doesn't write symbolic link header paths in the pcm modules,
this makes the listeners on the reader only able to collect the real files.

Since the module maps could contain submodules that use headers which
are symbolic links, not collecting those forbid the reproducer scripts
to regen the modules.

For instance:

usr/include/module.map:
  ...
  module pthread {
    header "pthread.h"
    export *

    module impl {
      header "pthread_impl.h"
      export *
    }
  }
  ...

usr/include/pthread/pthread_impl.h
usr/include/pthread_impl.h -> pthread/pthread_impl.h

The AST dump for the module above:

  <SUBMODULE_HEADER abbrevid=6/> blob data = 'pthread_impl.h'
  <SUBMODULE_TOPHEADER abbrevid=7/> blob data = '/<path_to_sdk>/usr/include/pthread/pthread_impl.h'

Note that we don't have "usr/include/pthread_impl.h" which is requested
by the module.map in case we want to reconstruct the module in the
reproducer. The reason the original symbolic link path isn't used is
because the headers are kept by name and requested through the
FileManager, which unique files and returns the real path only.

To fix that, add a callback to be invoked everytime a header is added
while parsing module maps and hook that up to the module dependecy
collector. This callback is only registered when generating the
reproducer.

Differential Revision: http://reviews.llvm.org/D18585

rdar://problem/24499339

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@264971 91177308-0d34-0410-b5e6-96231b3b80d8

implementation units of modules rather than interface units.


git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@263449 91177308-0d34-0410-b5e6-96231b3b80d8

option. Previously these options could both be used to specify that you were
compiling the implementation file of a module, with a different set of minor
bugs in each case.

This change removes -fmodule-implementation-of, and instead tracks a flag to
determine whether we're currently building a module. -fmodule-name now behaves
the same way that -fmodule-implementation-of previously did.


git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@261372 91177308-0d34-0410-b5e6-96231b3b80d8

Summary: It breaks the build for the ASTMatchers

Subscribers: klimek, cfe-commits

Differential Revision: http://reviews.llvm.org/D13893

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@250827 91177308-0d34-0410-b5e6-96231b3b80d8

Summary: Replace empty bodies of default constructors and destructors with '= default'.

Reviewers: bkramer, klimek

Subscribers: klimek, alexfh, cfe-commits

Differential Revision: http://reviews.llvm.org/D13890

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@250822 91177308-0d34-0410-b5e6-96231b3b80d8

[modules] Remove unnecessary deserialization of fully-external HeaderFileInfos for all files we've seen in this compilation.


git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@245881 91177308-0d34-0410-b5e6-96231b3b80d8

[modules] Fix HeaderFileInfo serialization to store all the known owning modules for a header, not just the current favourite.


git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@245390 91177308-0d34-0410-b5e6-96231b3b80d8

current compilation, not just those from imported modules.


git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@244413 91177308-0d34-0410-b5e6-96231b3b80d8

[modules] When diagnosing errors in module map files found by 'extern module' declarations, show how we got to that module map file.


git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@242105 91177308-0d34-0410-b5e6-96231b3b80d8

We use findModuleForHeader() in several places, but in header search we
were not calling it when a framework module didn't show up with the
expected name, which would then lead to unexpected non-modular includes.
Now we will find the module unconditionally for frameworks.  For regular
frameworks, we use the spelling of the module name from the module map
file, and for inferred ones we use the canonical directory name.

In the future we might want to lock down framework modules sufficiently
that these name mismatches cannot happen.

rdar://problem/20465870

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@241258 91177308-0d34-0410-b5e6-96231b3b80d8

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@240353 91177308-0d34-0410-b5e6-96231b3b80d8

The patch is generated using this command:

  $ tools/extra/clang-tidy/tool/run-clang-tidy.py -fix \
      -checks=-*,llvm-namespace-comment -header-filter='llvm/.*|clang/.*' \
      work/llvm/tools/clang

To reduce churn, not touching namespaces spanning less than 10 lines.



git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@240270 91177308-0d34-0410-b5e6-96231b3b80d8

The RequestingModule argument was unused and always its default value of
nullptr.

Also move a declaration closer to its use, and range-for'ify.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@239453 91177308-0d34-0410-b5e6-96231b3b80d8

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@239123 91177308-0d34-0410-b5e6-96231b3b80d8

[modules] Retain the name as written for umbrella headers and directories, rather than converting to an absolute path. No observable change expected, but this allows us to correctly compute the module for an umbrella header, which later changes will require.


git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@237508 91177308-0d34-0410-b5e6-96231b3b80d8

It has no place there; it's not a property of the Module, and it makes
restoring the visibility set when we leave a submodule more difficult.


git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@236300 91177308-0d34-0410-b5e6-96231b3b80d8

Removing LLVM_EXPLICIT, as MSVC 2012 was the last reason for requiring the macro. NFC; Clang edition.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@229336 91177308-0d34-0410-b5e6-96231b3b80d8

If a module map contains
framework module * [extern_c] {}

We will now infer [extern_c] on the inferred framework modules (we
already inferred [system] as a special case).

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@225803 91177308-0d34-0410-b5e6-96231b3b80d8

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@225801 91177308-0d34-0410-b5e6-96231b3b80d8

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


git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@223913 91177308-0d34-0410-b5e6-96231b3b80d8

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.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@223759 91177308-0d34-0410-b5e6-96231b3b80d8

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


git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@223753 91177308-0d34-0410-b5e6-96231b3b80d8

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.


git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@223095 91177308-0d34-0410-b5e6-96231b3b80d8

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@220589 91177308-0d34-0410-b5e6-96231b3b80d8

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.


git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@220460 91177308-0d34-0410-b5e6-96231b3b80d8

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.


git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@220448 91177308-0d34-0410-b5e6-96231b3b80d8

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.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@215455 91177308-0d34-0410-b5e6-96231b3b80d8

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@215316 91177308-0d34-0410-b5e6-96231b3b80d8

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.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@215268 91177308-0d34-0410-b5e6-96231b3b80d8

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@208063 91177308-0d34-0410-b5e6-96231b3b80d8

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.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@208004 91177308-0d34-0410-b5e6-96231b3b80d8

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@206595 91177308-0d34-0410-b5e6-96231b3b80d8

To differentiate between two modules with the same name, we will
consider the path the module map file that they are defined by* part of
the ‘key’ for looking up the precompiled module (pcm file).
Specifically, this patch renames the precompiled module (pcm) files from
  cache-path/<module hash>/Foo.pcm
to
  cache-path/<module hash>/Foo-<hash of module map path>.pcm

In addition, I’ve taught the ASTReader to re-resolve the names of
imported modules during module loading so that if the header search
context changes between when a module was originally built and when it
is loaded we can rebuild it if necessary.  For example, if module A
imports module B

first time:
clang -I /path/to/A -I /path/to/B ...

second time:
clang -I /path/to/A -I /different/path/to/B ...

will now rebuild A as expected.

* in the case of inferred modules, we use the module map file that
allowed the inference, not the __inferred_module.map file, since the
inferred file path is the same for every inferred module.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@206201 91177308-0d34-0410-b5e6-96231b3b80d8

No functional change intended.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@205942 91177308-0d34-0410-b5e6-96231b3b80d8

directory in module B, don't include it in module B!


git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@205762 91177308-0d34-0410-b5e6-96231b3b80d8

If a header file belonging to a certain module is not found on the
filesystem, that header gets marked as unavailable. Now, the layering
warning (-fmodules-decluse) should still warn about headers of this
module being wrongfully included. Currently, headers belonging to those
modules are just treated as not belonging to modules at all which means
they can be included freely from everywhere.

To implement this (somewhat) cleanly, I have moved most of the layering
checks into the ModuleMap. This will also help with showing FixIts
later.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@197805 91177308-0d34-0410-b5e6-96231b3b80d8