Track shadow modules with a generation counter.

This is a follow up to r321855, closing the gap between our internal shadow
modules implementation and upstream. It has been tested for longer and
pro

Track shadow modules with a generation counter.

This is a follow up to r321855, closing the gap between our internal shadow
modules implementation and upstream. It has been tested for longer and
provides a better approach for tracking shadow modules. Mostly NFCI.

rdar://problem/23612102

llvm-svn: 321906

show more ...

Reapply r321781: [Modules] Allow modules specified by -fmodule-map-file to shadow implicitly found ones

When modules come from module map files explicitly specified by
-fmodule-map-file= arguments,

Reapply r321781: [Modules] Allow modules specified by -fmodule-map-file to shadow implicitly found ones

When modules come from module map files explicitly specified by
-fmodule-map-file= arguments, allow those to override/shadow modules
with the same name that are found implicitly by header search. If such a
module is looked up by name (e.g. @import), we will always find the one
from -fmodule-map-file. If we try to use a shadowed module by including
one of its headers report an error.

This enables developers to force use of a specific copy of their module
to be used if there are multiple copies that would otherwise be visible,
for example if they develop modules that are installed in the default
search paths.

Patch originally by Ben Langmuir,
http://lists.llvm.org/pipermail/cfe-commits/Week-of-Mon-20151116/143425.html

Based on cfe-dev discussion:
http://lists.llvm.org/pipermail/cfe-dev/2015-November/046164.html

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

rdar://problem/23612102

llvm-svn: 321855

show more ...

Revert "[Modules] Allow modules specified by -fmodule-map-file to shadow implicitly found ones"

This reverts r321781 until I fix the leaks pointed out by bots:

http://lab.llvm.org:8011/builders/san

Revert "[Modules] Allow modules specified by -fmodule-map-file to shadow implicitly found ones"

This reverts r321781 until I fix the leaks pointed out by bots:

http://lab.llvm.org:8011/builders/sanitizer-x86_64-linux-fast/builds/12146
http://lab.llvm.org:8011/builders/sanitizer-x86_64-linux-bootstrap/builds/3741

llvm-svn: 321786

show more ...

[Modules] Allow modules specified by -fmodule-map-file to shadow implicitly found ones

When modules come from module map files explicitly specified by
-fmodule-map-file= arguments, allow those to ov

[Modules] Allow modules specified by -fmodule-map-file to shadow implicitly found ones

When modules come from module map files explicitly specified by
-fmodule-map-file= arguments, allow those to override/shadow modules
with the same name that are found implicitly by header search. If such a
module is looked up by name (e.g. @import), we will always find the one
from -fmodule-map-file. If we try to use a shadowed module by including
one of its headers report an error.

This enables developers to force use of a specific copy of their module
to be used if there are multiple copies that would otherwise be visible,
for example if they develop modules that are installed in the default
search paths.

Patch originally by Ben Langmuir,
http://lists.llvm.org/pipermail/cfe-commits/Week-of-Mon-20151116/143425.html

Based on cfe-dev discussion:
http://lists.llvm.org/pipermail/cfe-dev/2015-November/046164.html

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

rdar://problem/23612102

llvm-svn: 321781

show more ...

[Modules] Change private modules rules and warnings

We used to advertise private modules to be declared as submodules
(Foo.Private). This has proven to not scale well since private headers
might car

[Modules] Change private modules rules and warnings

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

llvm-svn: 321337

show more ...

[Lex] Fix some Clang-tidy modernize and Include What You Use warnings; other minor fixes (NFC).

llvm-svn: 319986

[Module map] Introduce a private module re-export directive.

Introduce a new "export_as" directive for top-level modules, which
indicates that the current module is a "private" module whose symbols

[Module map] Introduce a private module re-export directive.

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.

llvm-svn: 313316

show more ...

Fix memory leak after r312467. The ModuleMap is the owner of the global module object until it's reparented under a real module.

llvm-svn: 312580

Implement Itanium name mangling support for C++ Modules TS.

This follows the scheme agreed with Nathan Sidwell, which can be found here:

https://gcc.gnu.org/wiki/cxx-modules?action=AttachFile

Th

Implement Itanium name mangling support for C++ Modules TS.

This follows the scheme agreed with Nathan Sidwell, which can be found here:

https://gcc.gnu.org/wiki/cxx-modules?action=AttachFile

This will be proposed to the itanium-cxx-abi list once we have some experience
with how well it works; the ABI for this TS should be considered unstable until
it is part of the Itanium C++ ABI.

llvm-svn: 312467

show more ...

Track the set of module maps read while building a .pcm file and reload those when preprocessing from that .pcm file.

llvm-svn: 306628

Support lazy stat'ing of files referenced by module maps.

This patch adds support for a `header` declaration in a module map to specify
certain `stat` information (currently, size and mtime) about t

Support lazy stat'ing of files referenced by module maps.

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

llvm-svn: 304515

show more ...

Factor resolving of header directives -> files out of module map parser.

llvm-svn: 303945

Remove last (unnecessary) use of mapping from SourceLocation to Module and
remove the mechanism for doing so.

This mechanism was incorrect in the presence of preprocessed modules (and
#pragma clang

Remove last (unnecessary) use of mapping from SourceLocation to Module and
remove the mechanism for doing so.

This mechanism was incorrect in the presence of preprocessed modules (and
#pragma clang module begin/end).

llvm-svn: 303469

show more ...

[Modules] Allow umbrella frameworks to define private submodules for subframeworks

In r298391 we fixed the umbrella framework model to work when submodules
named "Private" are used. This complements

[Modules] Allow umbrella frameworks to define private submodules for subframeworks

In r298391 we fixed the umbrella framework model to work when submodules
named "Private" are used. This complements the work by allowing the
umbrella framework model to work in general.

rdar://problem/31790067

llvm-svn: 302491

show more ...

If we are building a module, and we read a second description of the same
module from a different module map, ignore it.

This happens during builds of preprocessed modules (where it is harmless).

l

If we are building a module, and we read a second description of the same
module from a different module map, ignore it.

This happens during builds of preprocessed modules (where it is harmless).

llvm-svn: 302463

show more ...

Add support for building modules from preprocessed source.

To support this, an optional marker "#pragma clang module contents" is
recognized in module map files, and the rest of the module map file

Add support for building modules from preprocessed source.

To support this, an optional marker "#pragma clang module contents" is
recognized in module map files, and the rest of the module map file from that
point onwards is treated as the source of the module. Preprocessing a module
map produces the input module followed by the marker and then the preprocessed
contents of the module.

Ignoring line markers, a preprocessed module might look like this:

module A {
header "a.h"
}
#pragma clang module contents
#pragma clang module begin A
// ... a.h ...
#pragma clang module end

The preprocessed output generates line markers, which are not accepted by the
module map parser, so -x c++-module-map-cpp-output should be used to compile
such outputs.

A couple of major parts do not work yet:

1) The files that are listed in the module map must exist on disk, in order to
build the on-disk header -> module lookup table in the PCM file. To fix
this, we need the preprocessed output to track the file size and other stat
information we might use to build the lookup table.

2) Declaration ownership semantics don't work properly yet, since mapping from
a source location to a module relies on mapping from FileIDs to modules,
which we can't do if module transitions can occur in the middle of a file.

llvm-svn: 302309

show more ...

[modules ts] Diagnose 'export' declarations outside of a module interface.

llvm-svn: 301271

PR30508: Downgrade error to warning if the umbrella folder doesn't exist.

Patch by Yuka Takahashi (D32119)!

llvm-svn: 300594

Modular Codegen: Separate flags for function and debug info support

This allows using and testing these two features separately. (noteably,
debug info is, so far as I know, always a win (basically).

Modular Codegen: Separate flags for function and debug info support

This allows using and testing these two features separately. (noteably,
debug info is, so far as I know, always a win (basically). But function
modular codegen is currently a loss for highly optimized code - where
most of the linkonce_odr definitions are optimized away, so providing
weak_odr definitions is only overhead)

llvm-svn: 300104

show more ...

[Modules] Find PrivateHeaders when looking into subframeworks

Fix the current parsing of subframeworks in modulemaps to lookup for
headers based on whether they are frameworks.

rdar://problem/30563

[Modules] Find PrivateHeaders when looking into subframeworks

Fix the current parsing of subframeworks in modulemaps to lookup for
headers based on whether they are frameworks.

rdar://problem/30563982

llvm-svn: 298391

show more ...

Fix modules codegen to be compatible with modules-ts

The Module::WithCodegen flag was only being set when the module was
parsed from a ModuleMap. Instead set it late, in the ASTWriter to match
the l

Fix modules codegen to be compatible with modules-ts

The Module::WithCodegen flag was only being set when the module was
parsed from a ModuleMap. Instead set it late, in the ASTWriter to match
the layer where the MODULAR_CODEGEN_DECLs list is determined (the
WithCodegen flag essentially means "are this module's decls in
MODULAR_CODEGEN_DECLs").

When simultaneous emission of AST file and modular object is implemented
this may need to change - the Module::WithCodegen flag will need to be
set earlier, and ideally the MODULAR_CODEGEN_DECLs gathering will
consult this flag (that's not possible right now since Decls destined
for an AST File don't have a Module - only if they're /read/ from a
Module is that true - I expect that would need to change as well).

llvm-svn: 293692

show more ...

Prototype of modules codegen

First pass at generating weak definitions of inline functions from module files
(& skipping (-O0) or emitting available_externally (optimizations)
definitions where thos

Prototype of modules codegen

First pass at generating weak definitions of inline functions from module files
(& skipping (-O0) or emitting available_externally (optimizations)
definitions where those modules are used).

External functions defined in modules are emitted into the modular
object file as well (this may turn an existing ODR violation (if that
module were imported into multiple translations) into valid/linkable
code).

Internal symbols (static functions, for example) are not correctly
supported yet. The symbol will be produced, internal, in the modular
object - unreferenceable from the users.

Reviewers: rsmith

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

llvm-svn: 293456

show more ...

[Modules] Fix misleading warning about missing textual header in umbrella header

When a textual header is present inside a umbrella dir but not in the
header, we get the misleading warning:

warning

[Modules] Fix misleading warning about missing textual header in umbrella header

When a textual header is present inside a umbrella dir but not in the
header, we get the misleading warning:

warning: umbrella header for module 'FooFramework' does not include
header 'Baz_Private.h'

The module map in question:

framework module FooFramework {
umbrella header "FooUmbrella.h"

export *
module * { export * }

module Private {
textual header "Baz_Private.h"
}
}

Fix this by taking textual headers into account.

llvm-svn: 291794

show more ...

[Modules] Support #import when entering files with modules

Textual headers and builtins that are #import'd from different
modules should get re-entered when these modules are independent
from each o

[Modules] Support #import when entering files with modules

Textual headers and builtins that are #import'd from different
modules should get re-entered when these modules are independent
from each other.

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

rdar://problem/25881934

llvm-svn: 291644

show more ...

Use after move bug fixes

Summary: Bunch of fixed bugs in Clang after running misc-use-after-move in clang-tidy.

Reviewers: rsmith, mboehme

Subscribers: cfe-commits, klimek

Differential Revision:

Use after move bug fixes

Summary: Bunch of fixed bugs in Clang after running misc-use-after-move in clang-tidy.

Reviewers: rsmith, mboehme

Subscribers: cfe-commits, klimek

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

llvm-svn: 290424

show more ...