]> granicus.if.org Git - clang/commit
[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)
commitdc4d70cd0ea93226d43105b8035caff2884f5587
tree6ab529350b5d847a9d4399aa4eb6a64c66bb80e7
parent773786df292c364357db2e9225092d272a9daf55
[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

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@290219 91177308-0d34-0410-b5e6-96231b3b80d8
include/clang/Basic/DiagnosticGroups.td
include/clang/Basic/DiagnosticLexKinds.td
include/clang/Lex/HeaderSearch.h
lib/Lex/HeaderSearch.cpp
lib/Lex/ModuleMap.cpp
test/Modules/Inputs/implicit-private-with-different-name/A.framework/Headers/a.h [new file with mode: 0644]
test/Modules/Inputs/implicit-private-with-different-name/A.framework/Headers/aprivate.h [new file with mode: 0644]
test/Modules/Inputs/implicit-private-with-different-name/A.framework/Modules/module.modulemap [new file with mode: 0644]
test/Modules/Inputs/implicit-private-with-different-name/A.framework/Modules/module.private.modulemap [new file with mode: 0644]
test/Modules/implicit-private-with-different-name.m [new file with mode: 0644]