summaryrefslogtreecommitdiffstats
path: root/include/clang/Lex
diff options
context:
space:
mode:
authorGraydon Hoare <ghoare@apple.com>2016-12-21 00:24:39 +0000
committerGraydon Hoare <ghoare@apple.com>2016-12-21 00:24:39 +0000
commitdc4d70cd0ea93226d43105b8035caff2884f5587 (patch)
tree6ab529350b5d847a9d4399aa4eb6a64c66bb80e7 /include/clang/Lex
parent773786df292c364357db2e9225092d272a9daf55 (diff)
[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
Diffstat (limited to 'include/clang/Lex')
-rw-r--r--include/clang/Lex/HeaderSearch.h13
1 files changed, 13 insertions, 0 deletions
diff --git a/include/clang/Lex/HeaderSearch.h b/include/clang/Lex/HeaderSearch.h
index 60214df783..b145d7bae1 100644
--- a/include/clang/Lex/HeaderSearch.h
+++ b/include/clang/Lex/HeaderSearch.h
@@ -547,6 +547,19 @@ public:
void loadTopLevelSystemModules();
private:
+
+ /// \brief Lookup a module with the given module name and search-name.
+ ///
+ /// \param ModuleName The name of the module we're looking for.
+ ///
+ /// \param SearchName The "search-name" to derive filesystem paths from
+ /// when looking for the module map; this is usually equal to ModuleName,
+ /// but for compatibility with some buggy frameworks, additional attempts
+ /// may be made to find the module under a related-but-different search-name.
+ ///
+ /// \returns The module named ModuleName.
+ Module *lookupModule(StringRef ModuleName, StringRef SearchName);
+
/// \brief Retrieve a module with the given name, which may be part of the
/// given framework.
///