We used to advertise private modules to be declared as submodules
(Foo.Private). This has proven to not scale well since private headers
might carry several dependencies, introducing unwanted content into the
main module and often causing dep cycles.

Change the canonical way to name it to Foo_Private, forcing private
modules as top level ones, and provide warnings under -Wprivate-module
to suggest fixes for other private naming. Update documentation to
reflect that.

rdar://problem/31173501

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

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

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

Introduce a new "export_as" directive for top-level modules, which
indicates that the current module is a "private" module whose symbols
will eventually be exported through the named "public" module. This is
in support of a common pattern in the Darwin ecosystem where a single
public framework is constructed of several private frameworks, with
(currently) header duplication and some support from the linker.

Addresses rdar://problem/34438420.

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

Extend the -fmodule-file option to support the [<name>=]<file> value format.
If the name is omitted, then the old semantics is preserved (the module file
is loaded whether needed or not). If the name is specified, then the mapping
is treated as just another prebuilt module search mechanism, similar to
-fprebuilt-module-path, and the module file is only loaded if actually used
(e.g., via import). With one exception: this mapping also overrides module
file references embedded in other modules (which can be useful if module files
are moved/renamed as often happens during remote compilation).

This override semantics requires some extra work: we now store the module name
in addition to the file name in the serialized AST representation.

Reviewed By: rsmith

Differential Revision: https://reviews.llvm.org/D35020



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

Looks like it breaks win10 builder.


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

Extend the -fmodule-file option to support the [<name>=]<file> value format.
If the name is omitted, then the old semantics is preserved (the module file
is loaded whether needed or not). If the name is specified, then the mapping
is treated as just another prebuilt module search mechanism, similar to
-fprebuilt-module-path, and the module file is only loaded if actually used
(e.g., via import). With one exception: this mapping also overrides module
file references embedded in other modules (which can be useful if module files
are moved/renamed as often happens during remote compilation).

This override semantics requires some extra work: we now store the module name
in addition to the file name in the serialized AST representation.

Reviewed By: rsmith

Differential Revision: https://reviews.llvm.org/D35020



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

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

Patch by ~paul (cynecx on phabricator)! Some test massaging by me.


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

This patch adds support for a `header` declaration in a module map to specify
certain `stat` information (currently, size and mtime) about that header file.
This has two purposes:

- It removes the need to eagerly `stat` every file referenced by a module map.
  Instead, we track a list of unresolved header files with each size / mtime
  (actually, for simplicity, we track submodules with such headers), and when
  attempting to look up a header file based on a `FileEntry`, we check if there
  are any unresolved header directives with that `FileEntry`'s size / mtime and
  perform deferred `stat`s if so.

- It permits a preprocessed module to be compiled without the original files
  being present on disk. The only reason we used to need those files was to get
  the `stat` information in order to do header -> module lookups when using the
  module. If we're provided with the `stat` information in the preprocessed
  module, we can avoid requiring the files to exist.

Unlike most `header` directives, if a `header` directive with `stat`
information has no corresponding on-disk file the enclosing module is *not*
marked unavailable (so that behavior is consistent regardless of whether we've
resolved a header directive, and so that preprocessed modules don't get marked
unavailable). We could actually do this for all `header` directives: the only
reason we mark the module unavailable if headers are missing is to give a
diagnostic slightly earlier (rather than waiting until we actually try to build
the module / load and validate its .pcm file).

Differential Revision: https://reviews.llvm.org/D33703


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

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

Summary: In order for libc++ to add `<experimental/coroutine>` to its module map, there has to be a feature that can be used to detect if coroutines support is enabled in Clang. 

Reviewers: rsmith

Reviewed By: rsmith

Subscribers: cfe-commits

Differential Revision: https://reviews.llvm.org/D33538

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

This reverts commit r304054.

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

Summary: In order for libc++ to add `<experimental/coroutine>` to its module map, there has to be a feature that can be used to detect if coroutines support is enabled in Clang. 

Reviewers: rsmith

Reviewed By: rsmith

Subscribers: cfe-commits

Differential Revision: https://reviews.llvm.org/D33538

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

Expand a bit on private modules with some guidance on how to write
them in the context of frameworks.

rdar://problem/24758771

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

-fbuiltin-module-map loads the clang builtins modulemap file. (This is
equivalent to -fmodule-map-file=<resource dir>/include/module.modulemap)

Differential Revision: https://reviews.llvm.org/D25767



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

The 'no_undeclared_includes' attribute should be used in a module to
tell that only non-modular headers and headers from used modules are
accepted.

The main motivation behind this is to prevent dep cycles between system
libraries (such as darwin) and libc++.

Patch by Richard Smith!

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

This adds support for modules that require (non-)freestanding
environment, such as the compiler builtin mm_malloc submodule.

Differential Revision: https://reviews.llvm.org/D23871



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

This adds support for modules that require (no-)gnu-inline-asm
environment, such as the compiler builtin cpuid submodule.

This is the gnu-inline-asm variant of https://reviews.llvm.org/D23871

Differential Revision: https://reviews.llvm.org/D23905

rdar://problem/26931199

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

In this mode, there is no need to load any module map and the programmer can
simply use "@import" syntax to load the module directly from a prebuilt
module path. When loading from prebuilt module path, we don't support
rebuilding of the module files and we ignore compatible configuration
mismatches.

rdar://27290316
Differential Revision: http://reviews.llvm.org/D23125


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

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

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

-fno-module-maps). The old names are preserved for compatibility.


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

These driver options never did anything (they weren't forwarded to the
frontend). Also update the documentation to not mention them.


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

modules, and allow sub-modules of a module with a use-declaration to make use
of the nominated modules.


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

If this flag is set, we error out when a module build is required. This is
useful in environments where all required modules are passed via -fmodule-file.

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

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


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

being on by default. -fno-cxx-modules can still be used to enable C modules but
not C++ modules, but C++ modules is not significantly less stable than C
modules any more.

Also remove some of the scare words from the modules documentation. We're
certainly not going to remove modules support (though we might change the
interface), and it works well enough to bootstrap and build lots of
non-trivial code.

Note that this does not represent a commitment to the current interface nor
implementation, and we still intend to follow whatever direction the C and C++
committees take regarding modules support.


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

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

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

Initial implementation of -modules-earch-all option, for searching for symbols in non-imported modules.

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

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

Don't install a file using the legacy spelling.

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

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

Requested in <rdar://problem/16188740>.


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

This name, while more verbose, plays more nicely with tools that use
file extensions to determine file types. The existing spelling
'module.map' will continue to work, but the new spelling will take
precedence.

In frameworks, this new filename will only go in a new 'Modules'
sub-directory.

Similarly, add a module.private.modulemap corresponding to
module_private.map.

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

Add [extern_c] attribute for modules, allowing a C module to be imported within an extern "C" block in C++ code.


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