Was causing warnings during the build.



git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@267805 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

While transient and only used during parsing, LocInfoTypes are still used
from ASTDumper and are part of the AST.

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

of the file name. This is consistent with how other HeaderSearchOptions
are handled.

Due to the other inputs of the module hash (revision number) this is not
really testable in a meaningful way.

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

Fixes PR25262

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@250844 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

Refactor module lookup when looking up a header file, and wire through the requesting module. No functionality change.


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

to enable the use of external type references in the debug info
(a.k.a. module debugging).

The driver expands -gmodules to "-g -fmodule-format=obj -dwarf-ext-refs"
and passes that to cc1. All this does at the moment is set a flag
codegenopts.

http://reviews.llvm.org/D11958

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@246192 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

when building with implicit modules disabled.


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

module cache has been provided, rather than creating one in the current
directory.


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

- introduces a new cc1 option -fmodule-format=[raw,obj]
  with 'raw' being the default
- supports arbitrary module container formats that libclang is agnostic to
- adds the format to the module hash to avoid collisions
- splits the old PCHContainerOperations into PCHContainerWriter and
  a PCHContainerReader.

Thanks to Richard Smith for reviewing this patch!

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

visible in the module we're considering entering. Previously we assumed that if
we knew the include guard for a modular header, we'd already parsed it, but
that need not be the case if a header is present in the current module and one
of its dependencies; the result of getting this wrong was that the current
module's submodule for the header would end up empty.


git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@241953 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

update the identifier in case we've imported a definition of the macro (and
thus the contents of the header) from a module.

Also fold ExternalIdentifierLookup into ExternalPreprocessorSource; it no longer
makes sense to keep these separate now that the only user of the former also
needs the latter.


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

re-entering a modular header.

When we do the include guard check, we're in the visibility state for the file
with the #include; the include guard may not be visible there, but we don't
actually need it to be: if we've already parsed the submodule we're considering
entering, it's always safe to skip it.


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

We used to have a flag to enable module maps, and two more flags to enable
implicit module maps. This is all redundant; we don't need any flag for
enabling module maps in the abstract, and we don't usually have -fno- flags for
-cc1. We now have just a single flag, -fimplicit-module-maps, that enables
implicitly searching the file system for module map files and loading them.

The driver interface is unchanged for now. We should probably rename
-fmodule-maps to -fimplicit-module-maps at some point.


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

[modules] If we see a #include that maps to a module, but use of precompiled modules is disabled, track submodule visibility anyway if -fmodules-local-submodule-visibility is enabled. This, in effect, gives modules semantics but without precompilation.


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

This reverts commit 9242ff16b0460b488691fd70b42a2bf81a531e3a.

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

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

Modules builds fundamentally have a non-linear macro history. In the interest
of better source fidelity, represent the macro definition information
faithfully: we have a linear macro directive history within each module, and at
any point we have a unique "latest" local macro directive and a collection of
visible imported directives. This also removes the attendent complexity of
attempting to create a correct MacroDirective history (which we got wrong
in the general case).

No functionality change intended.


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

Now that SmallString is a first-class citizen, most SmallString::str()
calls are not required. This patch removes a whole bunch of them, yet
there are lots more.

There are two use cases where str() is really needed:
1) To use one of StringRef member functions which is not available in
SmallString.
2) To convert to std::string, as StringRef implicitly converts while 
SmallString do not. We may wish to change this, but it may introduce
ambiguity.



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

This would cause frameworks to have spurious "redefinition" errors if
they had both a (legacy) "module.map" and a (new) "module.modulemap" file and we
happened to do a sub-directory search in that directory using a
non-framework include path (e.g. -Ifoo/ -Ffoo/).  For migration
purposes it's very handy that the compiler will prefer the new spelling
of the filename and not look at the old one if it doesn't need to.

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

While I investigate some possible problems with this patch.

This reverts commit r228966

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

When mangling the module map path into a .pcm file name, also mangle the
IsSystem bit, which can also depend on the header search paths. For
example, the user may change from -I to -isystem.  This can affect
diagnostics in the importing TU.

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

components. These sometimes get synthetically added, and we don't want -Ifoo
and -I./foo to be treated fundamentally differently here.


git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@224055 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

diagnostics if they don't exist. Based on a patch by John Thompson!


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

map path more canonical before hashing it. No functionality change.


git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@223547 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

This suppresses the implicit search for files called 'module.modulemap' and
similar.

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

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

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

loading multiple module map files from the same directory.


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

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

According to the gcc docs, -include uses the current working directory
for the lookup instead of the main source file.

This patch gets rid of NormalizeIncludePath (which relied on an
implementation detail of FileManager / FileEntry for the include path
logic to work), and instead hands the correct lookup information down to
LookupFile.

This will allow us to change the FileEntry's behavior regarding its Name
caching.

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