[modules] Handle modules with nonstandard names in module.private.modulemaps
authorGraydon Hoare <ghoare@apple.com>
Wed, 21 Dec 2016 00:24:39 +0000 (00:24 +0000)
committerGraydon Hoare <ghoare@apple.com>
Wed, 21 Dec 2016 00:24:39 +0000 (00:24 +0000)
commit4d8676407b8096e37a5d2df55ae329970a1f71e0
tree6a0b294ee3dcfa9cbdcfb71a0275e4700e32263d
parent1a21263a89bec0b159494e64adfcd988b72b6795
[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
clang/include/clang/Basic/DiagnosticGroups.td
clang/include/clang/Basic/DiagnosticLexKinds.td
clang/include/clang/Lex/HeaderSearch.h
clang/lib/Lex/HeaderSearch.cpp
clang/lib/Lex/ModuleMap.cpp
clang/test/Modules/Inputs/implicit-private-with-different-name/A.framework/Headers/a.h [new file with mode: 0644]
clang/test/Modules/Inputs/implicit-private-with-different-name/A.framework/Headers/aprivate.h [new file with mode: 0644]
clang/test/Modules/Inputs/implicit-private-with-different-name/A.framework/Modules/module.modulemap [new file with mode: 0644]
clang/test/Modules/Inputs/implicit-private-with-different-name/A.framework/Modules/module.private.modulemap [new file with mode: 0644]
clang/test/Modules/implicit-private-with-different-name.m [new file with mode: 0644]