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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@291794 91177308-0d34-0410-b5e6-96231b3b80d8
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
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@290219 91177308-0d34-0410-b5e6-96231b3b80d8
Thi way the compiler can pick the optimal storage duration. It's also
more readable. No functional change intended.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@287005 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@285152 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 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
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@279838 91177308-0d34-0410-b5e6-96231b3b80d8
interface files. At the moment, all declarations (and no macros) are exported,
and 'export' declarations are not supported yet.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@279794 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@269687 91177308-0d34-0410-b5e6-96231b3b80d8
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
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@269661 91177308-0d34-0410-b5e6-96231b3b80d8
(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
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
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
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@263076 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
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
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@253060 91177308-0d34-0410-b5e6-96231b3b80d8
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
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@245228 91177308-0d34-0410-b5e6-96231b3b80d8
Some compilers were less happy about converting a lambda to a comparator
function for array_pod_sort.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@244917 91177308-0d34-0410-b5e6-96231b3b80d8
This preserves backwards compatibility for two hacks in the Darwin
system module map files:
1. The use of 'requires excluded' to make headers non-modular, which
should really be mapped to 'textual' now that we have this feature.
2. Silently removes a bogus cplusplus requirement from IOKit.avc.
Once we start diagnosing missing requirements and headers on
auto-imports these would have broken compatibility with existing Darwin
SDKs.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@244912 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
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
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
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
With this change, enabling -fmodules-local-submodule-visibility results in name
visibility rules being applied to submodules of the current module in addition
to imported modules (that is, names no longer "leak" between submodules of the
same top-level module). This also makes it much safer to textually include a
non-modular library into a module: each submodule that textually includes that
library will get its own "copy" of that library, and so the library becomes
visible no matter which including submodule you import.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@237473 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
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
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
check that private headers are in a list matching the role. (We can't perform
the opposite checks for non-private headers because we infer those.)
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@231728 91177308-0d34-0410-b5e6-96231b3b80d8
Bruno Cardoso Lopes