[modules] Handle modules with nonstandard names in module.private.modulemaps

Summary:
The module system supports accompanying a primary module (say Foo) with
an auxiliary "private" module (defined i

[modules] Handle modules with nonstandard names in module.private.modulemaps

Summary:
The module system supports accompanying a primary module (say Foo) with
an auxiliary "private" module (defined in an adjacent module.private.modulemap
file) that augments the primary module when associated private headers are
available. The feature is intended to be used to augment the primary
module with a submodule (say Foo.Private), however some users in the wild
are choosing to augment the primary module with an additional top-level module
with a "similar" name (in all cases so far: FooPrivate).

This "works" when a user of the module initially imports a private header,
such as '#import "Foo/something_private.h"' since the Foo import winds up
importing FooPrivate in passing. But if the import is subsequently recorded
in a PCH file, reloading the PCH will fail to validate because of a cross-check
that attempts to find the module.modulemap (or module.private.modulemap) using
HeaderSearch algorithm, applied to the "FooPrivate" name. Since it's stored in
Foo.framework/Modules, not FooPrivate.framework/Modules, the check fails and
the PCH is rejected.

This patch adds a compensatory workaround in the HeaderSearch algorithm
when searching (and failing to find) a module of the form FooPrivate: the
name used to derive filesystem paths is decoupled from the module name
being searched for, and if the initial search fails and the module is
named "FooPrivate", the filesystem search name is altered to remove the
"Private" suffix, and the algorithm is run a second time (still looking for
a module named FooPrivate, but looking in directories derived from Foo).

Accompanying this change is a new warning that triggers when a user loads
a module.private.modulemap that defines a top-level module with a different
name from the top-level module defined in its adjacent module.modulemap.

Reviewers: doug.gregor, manmanren, bruno

Subscribers: bruno, cfe-commits

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

llvm-svn: 290219

show more ...

[Modules] Replace arrays with init lists.

Thi way the compiler can pick the optimal storage duration. It's also
more readable. No functional change intended.

llvm-svn: 287005

Treat module headers wrapped by our builtin headers as implicitly being textual
headers. We previously got this check backwards and treated the wrapper header
as being textual.

This is important bec

Treat module headers wrapped by our builtin headers as implicitly being textual
headers. We previously got this check backwards and treated the wrapper header
as being textual.

This is important because our wrapper headers sometimes inject macros into the
system headers that they #include_next, and sometimes replace them entirely.

llvm-svn: 285152

show more ...

Module: improve the diagnostic message for include of non-modular header.

Emit the actual path to the non-modular include.

rdar://28897010

llvm-svn: 284897

[Modules] Add 'no_undeclared_includes' module map attribute

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

[Modules] Add 'no_undeclared_includes' module map attribute

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!

llvm-svn: 284797

show more ...

Don't diagnose non-modular includes when we are not compiling a module.

This is triggered when we are compiling an implementation of a module,
it has relative includes to a VFS-mapped module with um

Don't diagnose non-modular includes when we are not compiling a module.

This is triggered when we are compiling an implementation of a module,
it has relative includes to a VFS-mapped module with umbrella headers.
Currently we will find the real path to headers under the umbrella directory,
but the umbrella directories are using virtual path.

rdar://27951255

Thanks Ben and Richard for reviewing the patch!
Differential Revision: http://reviews.llvm.org/D23858

llvm-svn: 279838

show more ...

C++ Modules TS: add frontend support for building pcm files from module
interface files. At the moment, all declarations (and no macros) are exported,
and 'export' declarations are not supported yet.

C++ Modules TS: add frontend support for building pcm files from module
interface files. At the moment, all declarations (and no macros) are exported,
and 'export' declarations are not supported yet.

llvm-svn: 279794

show more ...

[Lex] inferModuleFromLocation should do no work if there are no modules

getModuleContainingLocation ends up on the hot-path for typical C code
which can lead to calls to getFileIDSlow.

To speed thi

[Lex] inferModuleFromLocation should do no work if there are no modules

getModuleContainingLocation ends up on the hot-path for typical C code
which can lead to calls to getFileIDSlow.

To speed this up, short circuit inferModuleFromLocation when there
aren't any modules, implicit or otherwise.

This shaves 4-5% build time when building the linux kernel.

llvm-svn: 269687

show more ...

[Modules] Use vfs for (recursive) directory iteration

Clang performs directory walk while searching headers inside modules by
using the ::sys::fs instead of ::vfs. This prevents any code that uses
t

[Modules] Use vfs for (recursive) directory iteration

Clang performs directory walk while searching headers inside modules by
using the ::sys::fs instead of ::vfs. This prevents any code that uses
the VFS (e.g, reproducer scripts) to actually find such headers, since
the VFS will never be searched for those.

Change these places to use vfs::recursive_directory_iterator and
vfs::directory_iterator instead.

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

rdar://problem/25880368

llvm-svn: 269661

show more ...

[ModuleMap][CrashReproducer] Collect headers from inner frameworks

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

[ModuleMap][CrashReproducer] Collect headers from inner frameworks

(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

llvm-svn: 269502

show more ...

[CrashReproducer] Change module map callback signature. NFC

Use a StringRef instead of a FileEntry in the moduleMapAddHeader
callback to allow more flexibility on what to collect on further
patches.

[CrashReproducer] Change module map callback signature. NFC

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.

llvm-svn: 268819

show more ...

[modules] When diagnosing a missing module import, suggest adding a #include if
the current language doesn't have an import syntax and we can figure out a
suitable file to include.

llvm-svn: 267802

[CrashReproducer] Add a module map callback for added headers

The current ModuleDependencyCollector has a AST listener to collect
header files present in loaded modules, but this isn't enough to col

[CrashReproducer] Add a module map callback for added headers

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

llvm-svn: 264971

show more ...

[modules] Don't diagnose non-modular includes from modular files that are
implementation units of modules rather than interface units.

llvm-svn: 263449

[Modules] Add stdatomic to the list of builtin headers

Since it's provided by the compiler. This allows a system module map
file to declare a module for it.

No test change for cstd.m, since stdatom

[Modules] Add stdatomic to the list of builtin headers

Since it's provided by the compiler. This allows a system module map
file to declare a module for it.

No test change for cstd.m, since stdatomic.h doesn't function without a
relatively complete stdint.h and stddef.h, which tests using this module
don't provide.

rdar://problem/24931246

llvm-svn: 263076

show more ...

[Modules] Modernize, use range-based loops.

llvm-svn: 262969

[Modules] Don't swallow errors when parsing optional attributes.

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

llvm-svn: 262789

[modules] Flatten -fmodule-name= and -fmodule-implementation-of= into a single
option. Previously these options could both be used to specify that you were
compiling the implementation file of a modu

[modules] Flatten -fmodule-name= and -fmodule-implementation-of= into a single
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.

llvm-svn: 261372

show more ...

Annotate dump() methods with LLVM_DUMP_METHOD, addressing Richard Smith r259192 post commit comment.

llvm-svn: 259232

Fix auto-link for text-based dynamic library SDKs.

When linking against text-based dynamic library SDKs the library name of a
framework has now more than one possible filename extensions. This fix t

Fix auto-link for text-based dynamic library SDKs.

When linking against text-based dynamic library SDKs the library name of a
framework has now more than one possible filename extensions. This fix tests for
both possible extensions (none, and .tbd).

This fixes rdar://problem/20609975

llvm-svn: 253060

show more ...

Allow use of private headers in different sub-modules.

llvm-svn: 252170

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

llvm-svn: 245881

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

llvm-svn: 245390

[modules] PR20507: Avoid silent textual inclusion.

Summary:
If a module was unavailable (either a missing requirement on the module
being imported, or a missing file anywhere in the top-level module

[modules] PR20507: Avoid silent textual inclusion.

Summary:
If a module was unavailable (either a missing requirement on the module
being imported, or a missing file anywhere in the top-level module (and
not dominated by an unsatisfied `requires`)), we would silently treat
inclusions as textual. This would cause all manner of crazy and
confusing errors (and would also silently "work" sometimes, making the
problem difficult to track down).

I'm really not a fan of the `M->isAvailable(getLangOpts(), getTargetInfo(),
Requirement, MissingHeader)` function; it seems to do too many things at
once, but for now I've done things in a sort of awkward way.

The changes to test/Modules/Inputs/declare-use/module.map
were necessitated because the thing that was meant to be tested there
(introduced in r197805) was predicated on silently falling back to textual
inclusion, which we no longer do.

The changes to test/Modules/Inputs/macro-reexport/module.modulemap
are just an overlooked missing header that seems to have been missing since
this code was committed (r213922), which is now caught.

Reviewers: rsmith, benlangmuir, djasper

Subscribers: cfe-commits

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

llvm-svn: 245228

show more ...

Attempt to fix build after r244912

Some compilers were less happy about converting a lambda to a comparator
function for array_pod_sort.

llvm-svn: 244917