maxjhandsome
/
llvm-project
forked from OSchip/llvm-project
1
0
Fork 0
Code Issues Pull Requests Packages Releases Wiki Activity
llvm-project/clang/lib/Lex/ModuleMap.cpp

2535 lines
81 KiB
C++
Raw Normal View History

Introduce basic support for parsing module map files. Module map files provide a way to map between headers and modules, so that we can layer a module system on top of existing headers without changing those headers at all. This commit introduces the module map file parser and the module map that it generates, and wires up the module map file parser so that we'll automatically find module map files as part of header search. Note that we don't yet use the information stored in the module map. llvm-svn: 144402
2011-11-12 03:10:28 +08:00
//===--- ModuleMap.cpp - Describe the layout of modules ---------*- C++ -*-===//
//
// The LLVM Compiler Infrastructure
//
// This file is distributed under the University of Illinois Open Source
// License. See LICENSE.TXT for details.
//
//===----------------------------------------------------------------------===//
//
// This file defines the ModuleMap implementation, which describes the layout
// of a module as it relates to headers.
//
//===----------------------------------------------------------------------===//
#include "clang/Lex/ModuleMap.h"
Excise <cctype> from Clang (except clang-tblgen) in favor of CharInfo.h. Nearly all of these changes are one-to-one replacements; the few that aren't have to do with custom identifier validation. llvm-svn: 174768
2013-02-09 06:30:41 +08:00
#include "clang/Basic/CharInfo.h"
Introduce basic support for parsing module map files. Module map files provide a way to map between headers and modules, so that we can layer a module system on top of existing headers without changing those headers at all. This commit introduces the module map file parser and the module map that it generates, and wires up the module map file parser so that we'll automatically find module map files as part of header search. Note that we don't yet use the information stored in the module map. llvm-svn: 144402
2011-11-12 03:10:28 +08:00
#include "clang/Basic/Diagnostic.h"
Make DiagnosticOptions intrusively reference-counted, and make sure the various stakeholders bump up the reference count. In particular, the diagnostics engine now keeps the DiagnosticOptions object alive. llvm-svn: 166508
2012-10-24 06:26:28 +08:00
#include "clang/Basic/DiagnosticOptions.h"
Introduce basic support for parsing module map files. Module map files provide a way to map between headers and modules, so that we can layer a module system on top of existing headers without changing those headers at all. This commit introduces the module map file parser and the module map that it generates, and wires up the module map file parser so that we'll automatically find module map files as part of header search. Note that we don't yet use the information stored in the module map. llvm-svn: 144402
2011-11-12 03:10:28 +08:00
#include "clang/Basic/FileManager.h"
#include "clang/Basic/TargetInfo.h"
#include "clang/Basic/TargetOptions.h"
[Modules] Don't eagerly load and associate all the module header files. In a module-enabled Cocoa PCH file, we spend a lot of time stat'ing the headers in order to associate the FileEntries with their modules and support implicit module import. Use a more lazy scheme by enhancing HeaderInfoTable to store extra info about the module that a header belongs to, and associate it with its module only when there is a request for loading the header info for a particular file. Part of rdar://13391765 llvm-svn: 176976
2013-03-14 05:13:51 +08:00
#include "clang/Lex/HeaderSearch.h"
Reinstate r223753, reverted in r223759 due to breakage of clang-tools-extra. Original commit message: [modules] Add experimental -fmodule-map-file-home-is-cwd flag to -cc1. For files named by -fmodule-map-file=, and files found by 'extern module' directives, this flag specifies that we should resolve filenames relative to the current working directory rather than relative to the directory in which the module map file resides. This is aimed at fixing path handling, in particular for relative -I paths, when building modules that represent components of the current project (rather than libraries installed on the current system, which the current project has as dependencies, where we'd typically expect the module map files to be looked up implicitly). llvm-svn: 223913
2014-12-10 11:09:48 +08:00
#include "clang/Lex/HeaderSearchOptions.h"
Sort all of Clang's files under 'lib', and fix up the broken headers uncovered. This required manually correcting all of the incorrect main-module headers I could find, and running the new llvm/utils/sort_includes.py script over the files. I also manually added quite a few missing headers that were uncovered by shuffling the order or moving headers up to be main-module-headers. llvm-svn: 169237
2012-12-04 17:13:33 +08:00
#include "clang/Lex/LexDiagnostic.h"
#include "clang/Lex/Lexer.h"
#include "clang/Lex/LiteralSupport.h"
#include "llvm/ADT/StringRef.h"
#include "llvm/ADT/StringSwitch.h"
Introduce basic support for parsing module map files. Module map files provide a way to map between headers and modules, so that we can layer a module system on top of existing headers without changing those headers at all. This commit introduces the module map file parser and the module map that it generates, and wires up the module map file parser so that we'll automatically find module map files as part of header search. Note that we don't yet use the information stored in the module map. llvm-svn: 144402
2011-11-12 03:10:28 +08:00
#include "llvm/Support/Allocator.h"
When inferring a module map for a framework, infer subframework modules for each of its subframeworks. llvm-svn: 145957
2011-12-07 03:39:29 +08:00
#include "llvm/Support/FileSystem.h"
Introduce basic support for parsing module map files. Module map files provide a way to map between headers and modules, so that we can layer a module system on top of existing headers without changing those headers at all. This commit introduces the module map file parser and the module map that it generates, and wires up the module map file parser so that we'll automatically find module map files as part of header search. Note that we don't yet use the information stored in the module map. llvm-svn: 144402
2011-11-12 03:10:28 +08:00
#include "llvm/Support/Host.h"
Include Path.h instead of PathV2.h. I am about to move PathV2.h to Path.h. llvm-svn: 183795
2013-06-12 06:15:02 +08:00
#include "llvm/Support/Path.h"
Introduce basic support for parsing module map files. Module map files provide a way to map between headers and modules, so that we can layer a module system on top of existing headers without changing those headers at all. This commit introduces the module map file parser and the module map that it generates, and wires up the module map file parser so that we'll automatically find module map files as part of header search. Note that we don't yet use the information stored in the module map. llvm-svn: 144402
2011-11-12 03:10:28 +08:00
#include "llvm/Support/raw_ostream.h"
Following up on r164620, cope with symlinking from an embedded framework location out to a top-level framework. Such frameworks are not really embedded at all. llvm-svn: 164774
2012-09-27 22:50:15 +08:00
#include <stdlib.h>
Fix compilation on Linux, which defines PATH_MAX in a weird place, from Saleem Abdulrasool! llvm-svn: 173208
2013-01-23 07:49:45 +08:00
#if defined(LLVM_ON_UNIX)
<limits.h> includes <linux/limits.h> on Linux, no need to special-case it llvm-svn: 173578
2013-01-27 00:29:36 +08:00
#include <limits.h>
Fix compilation on Linux, which defines PATH_MAX in a weird place, from Saleem Abdulrasool! llvm-svn: 173208
2013-01-23 07:49:45 +08:00
#endif
Introduce basic support for parsing module map files. Module map files provide a way to map between headers and modules, so that we can layer a module system on top of existing headers without changing those headers at all. This commit introduces the module map file parser and the module map that it generates, and wires up the module map file parser so that we'll automatically find module map files as part of header search. Note that we don't yet use the information stored in the module map. llvm-svn: 144402
2011-11-12 03:10:28 +08:00
using namespace clang;
Implementing parsing and resolution of module export declarations within module maps, which will (eventually) be used to re-export a module from another module. There are still some pieces missing, however. llvm-svn: 145665
2011-12-02 09:47:07 +08:00
Module::ExportDecl
ModuleMap::resolveExport(Module *Mod,
const Module::UnresolvedExportDecl &Unresolved,
[modules] Const'ify some functions of ModuleMap. llvm-svn: 175552
2013-02-20 03:58:45 +08:00
bool Complain) const {
Implement support for wildcard exports in modules, allowing a module to re-export anything that it imports. This opt-in feature makes a module behave more like a header, because it can be used to re-export the transitive closure of a (sub)module's dependencies. llvm-svn: 145811
2011-12-06 01:28:06 +08:00
// We may have just a wildcard.
if (Unresolved.Id.empty()) {
assert(Unresolved.Wildcard && "Invalid unresolved export");
[C++11] Use 'nullptr'. Lex edition. llvm-svn: 209083
2014-05-18 07:10:59 +08:00
return Module::ExportDecl(nullptr, true);
Implement support for wildcard exports in modules, allowing a module to re-export anything that it imports. This opt-in feature makes a module behave more like a header, because it can be used to re-export the transitive closure of a (sub)module's dependencies. llvm-svn: 145811
2011-12-06 01:28:06 +08:00
}
<rdar://problem/12368093> Extend module maps with a 'conflict' declaration, and warn when a newly-imported module conflicts with an already-imported module. llvm-svn: 177577
2013-03-21 05:10:35 +08:00
// Resolve the module-id.
Module *Context = resolveModuleId(Unresolved.Id, Mod, Complain);
if (!Context)
return Module::ExportDecl();
return Module::ExportDecl(Context, Unresolved.Wildcard);
}
Module *ModuleMap::resolveModuleId(const ModuleId &Id, Module *Mod,
bool Complain) const {
Implementing parsing and resolution of module export declarations within module maps, which will (eventually) be used to re-export a module from another module. There are still some pieces missing, however. llvm-svn: 145665
2011-12-02 09:47:07 +08:00
// Find the starting module.
<rdar://problem/12368093> Extend module maps with a 'conflict' declaration, and warn when a newly-imported module conflicts with an already-imported module. llvm-svn: 177577
2013-03-21 05:10:35 +08:00
Module *Context = lookupModuleUnqualified(Id[0].first, Mod);
Implementing parsing and resolution of module export declarations within module maps, which will (eventually) be used to re-export a module from another module. There are still some pieces missing, however. llvm-svn: 145665
2011-12-02 09:47:07 +08:00
if (!Context) {
if (Complain)
Modules: Don't warn upon missing headers while reading the module map. Instead, mark the module as unavailable so that clang errors as soon as someone tries to build this module. This works towards the long-term goal of not stat'ing the header files at all while reading the module map and instead read them only when the module is being built (there is a corresponding FIXME in parseHeaderDecl()). However, it seems non-trivial to get there and this unblock us and moves us into the right direction. Also changed the implementation to reuse the same DiagnosticsEngine. llvm-svn: 197485
2013-12-17 18:31:37 +08:00
Diags.Report(Id[0].second, diag::err_mmap_missing_module_unqualified)
<rdar://problem/12368093> Extend module maps with a 'conflict' declaration, and warn when a newly-imported module conflicts with an already-imported module. llvm-svn: 177577
2013-03-21 05:10:35 +08:00
<< Id[0].first << Mod->getFullModuleName();
[C++11] Use 'nullptr'. Lex edition. llvm-svn: 209083
2014-05-18 07:10:59 +08:00
return nullptr;
Implementing parsing and resolution of module export declarations within module maps, which will (eventually) be used to re-export a module from another module. There are still some pieces missing, however. llvm-svn: 145665
2011-12-02 09:47:07 +08:00
}
// Dig into the module path.
<rdar://problem/12368093> Extend module maps with a 'conflict' declaration, and warn when a newly-imported module conflicts with an already-imported module. llvm-svn: 177577
2013-03-21 05:10:35 +08:00
for (unsigned I = 1, N = Id.size(); I != N; ++I) {
Module *Sub = lookupModuleQualified(Id[I].first, Context);
Implementing parsing and resolution of module export declarations within module maps, which will (eventually) be used to re-export a module from another module. There are still some pieces missing, however. llvm-svn: 145665
2011-12-02 09:47:07 +08:00
if (!Sub) {
if (Complain)
Modules: Don't warn upon missing headers while reading the module map. Instead, mark the module as unavailable so that clang errors as soon as someone tries to build this module. This works towards the long-term goal of not stat'ing the header files at all while reading the module map and instead read them only when the module is being built (there is a corresponding FIXME in parseHeaderDecl()). However, it seems non-trivial to get there and this unblock us and moves us into the right direction. Also changed the implementation to reuse the same DiagnosticsEngine. llvm-svn: 197485
2013-12-17 18:31:37 +08:00
Diags.Report(Id[I].second, diag::err_mmap_missing_module_qualified)
<rdar://problem/12368093> Extend module maps with a 'conflict' declaration, and warn when a newly-imported module conflicts with an already-imported module. llvm-svn: 177577
2013-03-21 05:10:35 +08:00
<< Id[I].first << Context->getFullModuleName()
<< SourceRange(Id[0].second, Id[I-1].second);
[C++11] Use 'nullptr'. Lex edition. llvm-svn: 209083
2014-05-18 07:10:59 +08:00
return nullptr;
Implementing parsing and resolution of module export declarations within module maps, which will (eventually) be used to re-export a module from another module. There are still some pieces missing, however. llvm-svn: 145665
2011-12-02 09:47:07 +08:00
}
<rdar://problem/12368093> Extend module maps with a 'conflict' declaration, and warn when a newly-imported module conflicts with an already-imported module. llvm-svn: 177577
2013-03-21 05:10:35 +08:00
Implementing parsing and resolution of module export declarations within module maps, which will (eventually) be used to re-export a module from another module. There are still some pieces missing, however. llvm-svn: 145665
2011-12-02 09:47:07 +08:00
Context = Sub;
}
<rdar://problem/12368093> Extend module maps with a 'conflict' declaration, and warn when a newly-imported module conflicts with an already-imported module. llvm-svn: 177577
2013-03-21 05:10:35 +08:00
return Context;
Implementing parsing and resolution of module export declarations within module maps, which will (eventually) be used to re-export a module from another module. There are still some pieces missing, however. llvm-svn: 145665
2011-12-02 09:47:07 +08:00
}
Modules: Don't warn upon missing headers while reading the module map. Instead, mark the module as unavailable so that clang errors as soon as someone tries to build this module. This works towards the long-term goal of not stat'ing the header files at all while reading the module map and instead read them only when the module is being built (there is a corresponding FIXME in parseHeaderDecl()). However, it seems non-trivial to get there and this unblock us and moves us into the right direction. Also changed the implementation to reuse the same DiagnosticsEngine. llvm-svn: 197485
2013-12-17 18:31:37 +08:00
ModuleMap::ModuleMap(SourceManager &SourceMgr, DiagnosticsEngine &Diags,
[Modules] Don't eagerly load and associate all the module header files. In a module-enabled Cocoa PCH file, we spend a lot of time stat'ing the headers in order to associate the FileEntries with their modules and support implicit module import. Use a more lazy scheme by enhancing HeaderInfoTable to store extra info about the module that a header belongs to, and associate it with its module only when there is a request for loading the header info for a particular file. Part of rdar://13391765 llvm-svn: 176976
2013-03-14 05:13:51 +08:00
const LangOptions &LangOpts, const TargetInfo *Target,
HeaderSearch &HeaderInfo)
Modules: Don't warn upon missing headers while reading the module map. Instead, mark the module as unavailable so that clang errors as soon as someone tries to build this module. This works towards the long-term goal of not stat'ing the header files at all while reading the module map and instead read them only when the module is being built (there is a corresponding FIXME in parseHeaderDecl()). However, it seems non-trivial to get there and this unblock us and moves us into the right direction. Also changed the implementation to reuse the same DiagnosticsEngine. llvm-svn: 197485
2013-12-17 18:31:37 +08:00
: SourceMgr(SourceMgr), Diags(Diags), LangOpts(LangOpts), Target(Target),
[C++11] Use 'nullptr'. Lex edition. llvm-svn: 209083
2014-05-18 07:10:59 +08:00
HeaderInfo(HeaderInfo), BuiltinIncludeDir(nullptr),
[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
2016-02-20 06:25:36 +08:00
SourceModule(nullptr), NumCreatedModules(0) {
[modules] Accept //-style comments in module maps on purpose rather than by accident, and accept them even when they begin '//*'. llvm-svn: 229240
2015-02-14 13:32:00 +08:00
MMapLangOpts.LineComment = true;
}
Introduce basic support for parsing module map files. Module map files provide a way to map between headers and modules, so that we can layer a module system on top of existing headers without changing those headers at all. This commit introduces the module map file parser and the module map that it generates, and wires up the module map file parser so that we'll automatically find module map files as part of header search. Note that we don't yet use the information stored in the module map. llvm-svn: 144402
2011-11-12 03:10:28 +08:00
ModuleMap::~ModuleMap() {
[Modules] Modernize, use range-based loops. llvm-svn: 262969
2016-03-09 07:58:08 +08:00
for (auto &M : Modules)
delete M.getValue();
Introduce basic support for parsing module map files. Module map files provide a way to map between headers and modules, so that we can layer a module system on top of existing headers without changing those headers at all. This commit introduces the module map file parser and the module map that it generates, and wires up the module map file parser so that we'll automatically find module map files as part of header search. Note that we don't yet use the information stored in the module map. llvm-svn: 144402
2011-11-12 03:10:28 +08:00
}
Thread a TargetInfo through to the module map; we'll need it for target-specific module requirements. llvm-svn: 149224
2012-01-30 14:01:29 +08:00
void ModuleMap::setTarget(const TargetInfo &Target) {
assert((!this->Target || this->Target == &Target) &&
"Improper target override");
this->Target = &Target;
}
Sanitize the names of modules determined based on the names of headers or directories, to make sure that they are identifiers that are not keywords in any dialect. Fixes <rdar://problem/12489495>. llvm-svn: 165821
2012-10-13 05:15:50 +08:00
/// \brief "Sanitize" a filename so that it can be used as an identifier.
static StringRef sanitizeFilenameAsIdentifier(StringRef Name,
SmallVectorImpl<char> &Buffer) {
if (Name.empty())
return Name;
Excise <cctype> from Clang (except clang-tblgen) in favor of CharInfo.h. Nearly all of these changes are one-to-one replacements; the few that aren't have to do with custom identifier validation. llvm-svn: 174768
2013-02-09 06:30:41 +08:00
if (!isValidIdentifier(Name)) {
Sanitize the names of modules determined based on the names of headers or directories, to make sure that they are identifiers that are not keywords in any dialect. Fixes <rdar://problem/12489495>. llvm-svn: 165821
2012-10-13 05:15:50 +08:00
// If we don't already have something with the form of an identifier,
// create a buffer with the sanitized name.
Buffer.clear();
Excise <cctype> from Clang (except clang-tblgen) in favor of CharInfo.h. Nearly all of these changes are one-to-one replacements; the few that aren't have to do with custom identifier validation. llvm-svn: 174768
2013-02-09 06:30:41 +08:00
if (isDigit(Name[0]))
Sanitize the names of modules determined based on the names of headers or directories, to make sure that they are identifiers that are not keywords in any dialect. Fixes <rdar://problem/12489495>. llvm-svn: 165821
2012-10-13 05:15:50 +08:00
Buffer.push_back('_');
Buffer.reserve(Buffer.size() + Name.size());
for (unsigned I = 0, N = Name.size(); I != N; ++I) {
Excise <cctype> from Clang (except clang-tblgen) in favor of CharInfo.h. Nearly all of these changes are one-to-one replacements; the few that aren't have to do with custom identifier validation. llvm-svn: 174768
2013-02-09 06:30:41 +08:00
if (isIdentifierBody(Name[I]))
Sanitize the names of modules determined based on the names of headers or directories, to make sure that they are identifiers that are not keywords in any dialect. Fixes <rdar://problem/12489495>. llvm-svn: 165821
2012-10-13 05:15:50 +08:00
Buffer.push_back(Name[I]);
else
Buffer.push_back('_');
}
Name = StringRef(Buffer.data(), Buffer.size());
}
while (llvm::StringSwitch<bool>(Name)
#define KEYWORD(Keyword,Conditions) .Case(#Keyword, true)
#define ALIAS(Keyword, AliasOf, Conditions) .Case(Keyword, true)
#include "clang/Basic/TokenKinds.def"
.Default(false)) {
if (Name.data() != Buffer.data())
Buffer.append(Name.begin(), Name.end());
Buffer.push_back('_');
Name = StringRef(Buffer.data(), Buffer.size());
}
return Name;
}
When looking for the module associated with one of our magical builtin headers, speculatively load module maps. The "magical" builtin headers are the headers we provide as part of the C standard library, which typically comes from /usr/include. We essentially merge our headers into that location (due to cyclic dependencies). This change makes sure that, when header search finds one of our builtin headers, we figure out which module it actually lives in. This case is fairly rare; one ends up having to include one of the few built-in C headers we provide before including anything from /usr/include to trigger it. Fixes <rdar://problem/13787184>. llvm-svn: 180934
2013-05-03 01:58:30 +08:00
/// \brief Determine whether the given file name is the name of a builtin
/// header, supplied by Clang to replace, override, or augment existing system
/// headers.
static bool isBuiltinHeader(StringRef FileName) {
return llvm::StringSwitch<bool>(FileName)
.Case("float.h", true)
.Case("iso646.h", true)
.Case("limits.h", true)
.Case("stdalign.h", true)
.Case("stdarg.h", true)
[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
2016-03-10 07:31:34 +08:00
.Case("stdatomic.h", true)
When looking for the module associated with one of our magical builtin headers, speculatively load module maps. The "magical" builtin headers are the headers we provide as part of the C standard library, which typically comes from /usr/include. We essentially merge our headers into that location (due to cyclic dependencies). This change makes sure that, when header search finds one of our builtin headers, we figure out which module it actually lives in. This case is fairly rare; one ends up having to include one of the few built-in C headers we provide before including anything from /usr/include to trigger it. Fixes <rdar://problem/13787184>. llvm-svn: 180934
2013-05-03 01:58:30 +08:00
.Case("stdbool.h", true)
.Case("stddef.h", true)
.Case("stdint.h", true)
.Case("tgmath.h", true)
.Case("unwind.h", true)
.Default(false);
}
Enable layering check in unavailable modules. If a header file belonging to a certain module is not found on the filesystem, that header gets marked as unavailable. Now, the layering warning (-fmodules-decluse) should still warn about headers of this module being wrongfully included. Currently, headers belonging to those modules are just treated as not belonging to modules at all which means they can be included freely from everywhere. To implement this (somewhat) cleanly, I have moved most of the layering checks into the ModuleMap. This will also help with showing FixIts later. llvm-svn: 197805
2013-12-20 20:09:36 +08:00
ModuleMap::HeadersMap::iterator
ModuleMap::findKnownHeader(const FileEntry *File) {
Introduce the notion of excluded headers into the module map description. Previously, one could emulate this behavior by placing the header in an always-unavailable submodule, but Argyrios guilted me into expressing this idea properly. llvm-svn: 165921
2012-10-15 14:28:11 +08:00
HeadersMap::iterator Known = Headers.find(File);
[modules] Simplify -cc1 interface for enabling implicit module maps. 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. llvm-svn: 239789
2015-06-16 08:08:24 +08:00
if (HeaderInfo.getHeaderSearchOpts().ImplicitModuleMaps &&
Known == Headers.end() && File->getDir() == BuiltinIncludeDir &&
Modules: Let -fmodules-decluse ignore headers that aren't in a module Includes might always pull in arbitrary header or data files outside of modules. Among others, this includes builtin includes, which do not have a module (story) yet. Also cleanup implementation of ModuleMap::findModuleForHeader() to be non-recursive. llvm-svn: 197034
2013-12-11 20:13:00 +08:00
isBuiltinHeader(llvm::sys::path::filename(File->getName()))) {
HeaderInfo.loadTopLevelSystemModules();
Enable layering check in unavailable modules. If a header file belonging to a certain module is not found on the filesystem, that header gets marked as unavailable. Now, the layering warning (-fmodules-decluse) should still warn about headers of this module being wrongfully included. Currently, headers belonging to those modules are just treated as not belonging to modules at all which means they can be included freely from everywhere. To implement this (somewhat) cleanly, I have moved most of the layering checks into the ModuleMap. This will also help with showing FixIts later. llvm-svn: 197805
2013-12-20 20:09:36 +08:00
return Headers.find(File);
Modules: Let -fmodules-decluse ignore headers that aren't in a module Includes might always pull in arbitrary header or data files outside of modules. Among others, this includes builtin includes, which do not have a module (story) yet. Also cleanup implementation of ModuleMap::findModuleForHeader() to be non-recursive. llvm-svn: 197034
2013-12-11 20:13:00 +08:00
}
Enable layering check in unavailable modules. If a header file belonging to a certain module is not found on the filesystem, that header gets marked as unavailable. Now, the layering warning (-fmodules-decluse) should still warn about headers of this module being wrongfully included. Currently, headers belonging to those modules are just treated as not belonging to modules at all which means they can be included freely from everywhere. To implement this (somewhat) cleanly, I have moved most of the layering checks into the ModuleMap. This will also help with showing FixIts later. llvm-svn: 197805
2013-12-20 20:09:36 +08:00
return Known;
}
Move search for header in umbrella directories into its own function No functional change intended. llvm-svn: 205942
2014-04-10 08:39:10 +08:00
ModuleMap::KnownHeader
ModuleMap::findHeaderInUmbrellaDirs(const FileEntry *File,
SmallVectorImpl<const DirectoryEntry *> &IntermediateDirs) {
[modules] Simplify -cc1 interface for enabling implicit module maps. 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. llvm-svn: 239789
2015-06-16 08:08:24 +08:00
if (UmbrellaDirs.empty())
return KnownHeader();
Move search for header in umbrella directories into its own function No functional change intended. llvm-svn: 205942
2014-04-10 08:39:10 +08:00
const DirectoryEntry *Dir = File->getDir();
assert(Dir && "file in no directory");
// Note: as an egregious but useful hack we use the real path here, because
// frameworks moving from top-level frameworks to embedded frameworks tend
// to be symlinked from the top-level location to the embedded location,
// and we need to resolve lookups as if we had found the embedded location.
StringRef DirName = SourceMgr.getFileManager().getCanonicalName(Dir);
// Keep walking up the directory hierarchy, looking for a directory with
// an umbrella header.
do {
auto KnownDir = UmbrellaDirs.find(Dir);
if (KnownDir != UmbrellaDirs.end())
return KnownHeader(KnownDir->second, NormalHeader);
IntermediateDirs.push_back(Dir);
// Retrieve our parent path.
DirName = llvm::sys::path::parent_path(DirName);
if (DirName.empty())
break;
// Resolve the parent path to a directory entry.
Dir = SourceMgr.getFileManager().getDirectory(DirName);
} while (Dir);
return KnownHeader();
}
Enable layering check in unavailable modules. If a header file belonging to a certain module is not found on the filesystem, that header gets marked as unavailable. Now, the layering warning (-fmodules-decluse) should still warn about headers of this module being wrongfully included. Currently, headers belonging to those modules are just treated as not belonging to modules at all which means they can be included freely from everywhere. To implement this (somewhat) cleanly, I have moved most of the layering checks into the ModuleMap. This will also help with showing FixIts later. llvm-svn: 197805
2013-12-20 20:09:36 +08:00
static bool violatesPrivateInclude(Module *RequestingModule,
const FileEntry *IncFileEnt,
[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
2016-04-28 05:57:05 +08:00
ModuleMap::KnownHeader Header) {
[modules] Support combining 'textual' with 'private'. llvm-svn: 220589
2014-10-25 04:23:01 +08:00
#ifndef NDEBUG
[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
2016-04-28 05:57:05 +08:00
if (Header.getRole() & ModuleMap::PrivateHeader) {
[modules] This check is run before we resolve the header, not after, so just 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.) llvm-svn: 231728
2015-03-10 08:19:04 +08:00
// Check for consistency between the module header role
// as obtained from the lookup and as obtained from the module.
// This check is not cheap, so enable it only for debugging.
bool IsPrivate = false;
SmallVectorImpl<Module::Header> *HeaderList[] = {
[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
2016-04-28 05:57:05 +08:00
&Header.getModule()->Headers[Module::HK_Private],
&Header.getModule()->Headers[Module::HK_PrivateTextual]};
[modules] This check is run before we resolve the header, not after, so just 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.) llvm-svn: 231728
2015-03-10 08:19:04 +08:00
for (auto *Hs : HeaderList)
IsPrivate |=
std::find_if(Hs->begin(), Hs->end(), [&](const Module::Header &H) {
[modules] Don't assert if the same header is named as both a public and a private header within the same module. llvm-svn: 231725
2015-03-10 07:46:50 +08:00
return H.Entry == IncFileEnt;
[modules] This check is run before we resolve the header, not after, so just 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.) llvm-svn: 231728
2015-03-10 08:19:04 +08:00
}) != Hs->end();
[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
2016-04-28 05:57:05 +08:00
assert(IsPrivate && "inconsistent headers and roles");
[modules] This check is run before we resolve the header, not after, so just 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.) llvm-svn: 231728
2015-03-10 08:19:04 +08:00
}
[modules] Support combining 'textual' with 'private'. llvm-svn: 220589
2014-10-25 04:23:01 +08:00
#endif
[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
2016-04-28 05:57:05 +08:00
return !Header.isAccessibleFrom(RequestingModule);
Enable layering check in unavailable modules. If a header file belonging to a certain module is not found on the filesystem, that header gets marked as unavailable. Now, the layering warning (-fmodules-decluse) should still warn about headers of this module being wrongfully included. Currently, headers belonging to those modules are just treated as not belonging to modules at all which means they can be included freely from everywhere. To implement this (somewhat) cleanly, I have moved most of the layering checks into the ModuleMap. This will also help with showing FixIts later. llvm-svn: 197805
2013-12-20 20:09:36 +08:00
}
Add -Wnon-modular-include* options Warn on non-modular includes in various contexts. -Wnon-modular-include -Wnon-modular-include-in-module -Wnon-modular-include-in-framework-module Where each group is a subgroup of those above it. llvm-svn: 208004
2014-05-06 05:44:13 +08:00
static Module *getTopLevelOrNull(Module *M) {
return M ? M->getTopLevelModule() : nullptr;
}
Enable layering check in unavailable modules. If a header file belonging to a certain module is not found on the filesystem, that header gets marked as unavailable. Now, the layering warning (-fmodules-decluse) should still warn about headers of this module being wrongfully included. Currently, headers belonging to those modules are just treated as not belonging to modules at all which means they can be included freely from everywhere. To implement this (somewhat) cleanly, I have moved most of the layering checks into the ModuleMap. This will also help with showing FixIts later. llvm-svn: 197805
2013-12-20 20:09:36 +08:00
void ModuleMap::diagnoseHeaderInclusion(Module *RequestingModule,
[modules] Don't diagnose non-modular includes from modular files that are implementation units of modules rather than interface units. llvm-svn: 263449
2016-03-15 01:52:37 +08:00
bool RequestingModuleIsModuleInterface,
Enable layering check in unavailable modules. If a header file belonging to a certain module is not found on the filesystem, that header gets marked as unavailable. Now, the layering warning (-fmodules-decluse) should still warn about headers of this module being wrongfully included. Currently, headers belonging to those modules are just treated as not belonging to modules at all which means they can be included freely from everywhere. To implement this (somewhat) cleanly, I have moved most of the layering checks into the ModuleMap. This will also help with showing FixIts later. llvm-svn: 197805
2013-12-20 20:09:36 +08:00
SourceLocation FilenameLoc,
StringRef Filename,
const FileEntry *File) {
// No errors for indirect modules. This may be a bit of a problem for modules
// with no source files.
Add -Wnon-modular-include* options Warn on non-modular includes in various contexts. -Wnon-modular-include -Wnon-modular-include-in-module -Wnon-modular-include-in-framework-module Where each group is a subgroup of those above it. llvm-svn: 208004
2014-05-06 05:44:13 +08:00
if (getTopLevelOrNull(RequestingModule) != getTopLevelOrNull(SourceModule))
Enable layering check in unavailable modules. If a header file belonging to a certain module is not found on the filesystem, that header gets marked as unavailable. Now, the layering warning (-fmodules-decluse) should still warn about headers of this module being wrongfully included. Currently, headers belonging to those modules are just treated as not belonging to modules at all which means they can be included freely from everywhere. To implement this (somewhat) cleanly, I have moved most of the layering checks into the ModuleMap. This will also help with showing FixIts later. llvm-svn: 197805
2013-12-20 20:09:36 +08:00
return;
if (RequestingModule)
resolveUses(RequestingModule, /*Complain=*/false);
Add -Wnon-modular-include* options Warn on non-modular includes in various contexts. -Wnon-modular-include -Wnon-modular-include-in-module -Wnon-modular-include-in-framework-module Where each group is a subgroup of those above it. llvm-svn: 208004
2014-05-06 05:44:13 +08:00
bool Excluded = false;
[C++11] Use 'nullptr'. Lex edition. llvm-svn: 209083
2014-05-18 07:10:59 +08:00
Module *Private = nullptr;
Module *NotUsed = nullptr;
Enable layering check in unavailable modules. If a header file belonging to a certain module is not found on the filesystem, that header gets marked as unavailable. Now, the layering warning (-fmodules-decluse) should still warn about headers of this module being wrongfully included. Currently, headers belonging to those modules are just treated as not belonging to modules at all which means they can be included freely from everywhere. To implement this (somewhat) cleanly, I have moved most of the layering checks into the ModuleMap. This will also help with showing FixIts later. llvm-svn: 197805
2013-12-20 20:09:36 +08:00
Add -Wnon-modular-include* options Warn on non-modular includes in various contexts. -Wnon-modular-include -Wnon-modular-include-in-module -Wnon-modular-include-in-framework-module Where each group is a subgroup of those above it. llvm-svn: 208004
2014-05-06 05:44:13 +08:00
HeadersMap::iterator Known = findKnownHeader(File);
if (Known != Headers.end()) {
for (const KnownHeader &Header : Known->second) {
// Remember private headers for later printing of a diagnostic.
[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
2016-04-28 05:57:05 +08:00
if (violatesPrivateInclude(RequestingModule, File, Header)) {
Add -Wnon-modular-include* options Warn on non-modular includes in various contexts. -Wnon-modular-include -Wnon-modular-include-in-module -Wnon-modular-include-in-framework-module Where each group is a subgroup of those above it. llvm-svn: 208004
2014-05-06 05:44:13 +08:00
Private = Header.getModule();
continue;
}
// If uses need to be specified explicitly, we are only allowed to return
// modules that are explicitly used by the requesting module.
if (RequestingModule && LangOpts.ModulesDeclUse &&
[modules] Restrict the module use-declaration to only appear in top-level modules, and allow sub-modules of a module with a use-declaration to make use of the nominated modules. llvm-svn: 233323
2015-03-27 06:10:01 +08:00
!RequestingModule->directlyUses(Header.getModule())) {
Add -Wnon-modular-include* options Warn on non-modular includes in various contexts. -Wnon-modular-include -Wnon-modular-include-in-module -Wnon-modular-include-in-framework-module Where each group is a subgroup of those above it. llvm-svn: 208004
2014-05-06 05:44:13 +08:00
NotUsed = Header.getModule();
continue;
}
// We have found a module that we can happily use.
return;
Enable layering check in unavailable modules. If a header file belonging to a certain module is not found on the filesystem, that header gets marked as unavailable. Now, the layering warning (-fmodules-decluse) should still warn about headers of this module being wrongfully included. Currently, headers belonging to those modules are just treated as not belonging to modules at all which means they can be included freely from everywhere. To implement this (somewhat) cleanly, I have moved most of the layering checks into the ModuleMap. This will also help with showing FixIts later. llvm-svn: 197805
2013-12-20 20:09:36 +08:00
}
Refactor implementation of 'exclude header'. This was not a real header role, and was never exposed to clients of ModuleMap. Remove the enumeration value for it and track it as marking the header as 'known' rather than creating an extra KnownHeader entry that *every single* client ignores. llvm-svn: 220460
2014-10-23 10:01:19 +08:00
Excluded = true;
Enable layering check in unavailable modules. If a header file belonging to a certain module is not found on the filesystem, that header gets marked as unavailable. Now, the layering warning (-fmodules-decluse) should still warn about headers of this module being wrongfully included. Currently, headers belonging to those modules are just treated as not belonging to modules at all which means they can be included freely from everywhere. To implement this (somewhat) cleanly, I have moved most of the layering checks into the ModuleMap. This will also help with showing FixIts later. llvm-svn: 197805
2013-12-20 20:09:36 +08:00
}
// We have found a header, but it is private.
[C++11] Use 'nullptr'. Lex edition. llvm-svn: 209083
2014-05-18 07:10:59 +08:00
if (Private) {
Allow errors on use of a private module header to be disabled, to better support incremental transition to modules. llvm-svn: 229788
2015-02-19 08:10:28 +08:00
Diags.Report(FilenameLoc, diag::warn_use_of_private_header_outside_module)
Enable layering check in unavailable modules. If a header file belonging to a certain module is not found on the filesystem, that header gets marked as unavailable. Now, the layering warning (-fmodules-decluse) should still warn about headers of this module being wrongfully included. Currently, headers belonging to those modules are just treated as not belonging to modules at all which means they can be included freely from everywhere. To implement this (somewhat) cleanly, I have moved most of the layering checks into the ModuleMap. This will also help with showing FixIts later. llvm-svn: 197805
2013-12-20 20:09:36 +08:00
<< Filename;
return;
}
// We have found a module, but we don't use it.
[C++11] Use 'nullptr'. Lex edition. llvm-svn: 209083
2014-05-18 07:10:59 +08:00
if (NotUsed) {
Allow errors on use of a private module header to be disabled, to better support incremental transition to modules. llvm-svn: 229788
2015-02-19 08:10:28 +08:00
Diags.Report(FilenameLoc, diag::err_undeclared_use_of_module)
Enable layering check in unavailable modules. If a header file belonging to a certain module is not found on the filesystem, that header gets marked as unavailable. Now, the layering warning (-fmodules-decluse) should still warn about headers of this module being wrongfully included. Currently, headers belonging to those modules are just treated as not belonging to modules at all which means they can be included freely from everywhere. To implement this (somewhat) cleanly, I have moved most of the layering checks into the ModuleMap. This will also help with showing FixIts later. llvm-svn: 197805
2013-12-20 20:09:36 +08:00
<< RequestingModule->getFullModuleName() << Filename;
return;
}
Add -Wnon-modular-include* options Warn on non-modular includes in various contexts. -Wnon-modular-include -Wnon-modular-include-in-module -Wnon-modular-include-in-framework-module Where each group is a subgroup of those above it. llvm-svn: 208004
2014-05-06 05:44:13 +08:00
if (Excluded || isHeaderInUmbrellaDirs(File))
return;
// At this point, only non-modular includes remain.
if (LangOpts.ModulesStrictDeclUse) {
Allow errors on use of a private module header to be disabled, to better support incremental transition to modules. llvm-svn: 229788
2015-02-19 08:10:28 +08:00
Diags.Report(FilenameLoc, diag::err_undeclared_use_of_module)
Add -Wnon-modular-include* options Warn on non-modular includes in various contexts. -Wnon-modular-include -Wnon-modular-include-in-module -Wnon-modular-include-in-framework-module Where each group is a subgroup of those above it. llvm-svn: 208004
2014-05-06 05:44:13 +08:00
<< RequestingModule->getFullModuleName() << Filename;
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
2016-08-27 01:16:46 +08:00
} else if (RequestingModule && RequestingModuleIsModuleInterface &&
LangOpts.isCompilingModule()) {
// Do not diagnose when we are not compiling a module.
Add -Wnon-modular-include* options Warn on non-modular includes in various contexts. -Wnon-modular-include -Wnon-modular-include-in-module -Wnon-modular-include-in-framework-module Where each group is a subgroup of those above it. llvm-svn: 208004
2014-05-06 05:44:13 +08:00
diag::kind DiagID = RequestingModule->getTopLevelModule()->IsFramework ?
diag::warn_non_modular_include_in_framework_module :
diag::warn_non_modular_include_in_module;
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
2016-10-22 07:27:37 +08:00
Diags.Report(FilenameLoc, DiagID) << RequestingModule->getFullModuleName()
<< File->getName();
Add -Wnon-modular-include* options Warn on non-modular includes in various contexts. -Wnon-modular-include -Wnon-modular-include-in-module -Wnon-modular-include-in-framework-module Where each group is a subgroup of those above it. llvm-svn: 208004
2014-05-06 05:44:13 +08:00
}
Enable layering check in unavailable modules. If a header file belonging to a certain module is not found on the filesystem, that header gets marked as unavailable. Now, the layering warning (-fmodules-decluse) should still warn about headers of this module being wrongfully included. Currently, headers belonging to those modules are just treated as not belonging to modules at all which means they can be included freely from everywhere. To implement this (somewhat) cleanly, I have moved most of the layering checks into the ModuleMap. This will also help with showing FixIts later. llvm-svn: 197805
2013-12-20 20:09:36 +08:00
}
[modules] If we have a choice between including a file textually and importing a prebuilt form from a module, prefer the modular form, all else being equal. llvm-svn: 229188
2015-02-14 07:50:20 +08:00
static bool isBetterKnownHeader(const ModuleMap::KnownHeader &New,
const ModuleMap::KnownHeader &Old) {
[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
2015-08-18 00:39:30 +08:00
// Prefer available modules.
if (New.getModule()->isAvailable() && !Old.getModule()->isAvailable())
return true;
[modules] If we have a choice between including a file textually and importing a prebuilt form from a module, prefer the modular form, all else being equal. llvm-svn: 229188
2015-02-14 07:50:20 +08:00
// Prefer a public header over a private header.
if ((New.getRole() & ModuleMap::PrivateHeader) !=
(Old.getRole() & ModuleMap::PrivateHeader))
return !(New.getRole() & ModuleMap::PrivateHeader);
// Prefer a non-textual header over a textual header.
if ((New.getRole() & ModuleMap::TextualHeader) !=
(Old.getRole() & ModuleMap::TextualHeader))
return !(New.getRole() & ModuleMap::TextualHeader);
// Don't have a reason to choose between these. Just keep the first one.
return false;
}
[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
2016-10-21 09:41:56 +08:00
ModuleMap::KnownHeader ModuleMap::findModuleForHeader(const FileEntry *File,
bool AllowTextual) {
[modules] Add support for 'textual header' directives. This allows a module to specify that it logically contains a file, but that said file is non-modular and intended for textual inclusion. This allows layering checks to work properly in the presence of such files. llvm-svn: 220448
2014-10-23 07:50:56 +08:00
auto MakeResult = [&](ModuleMap::KnownHeader R) -> ModuleMap::KnownHeader {
[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
2016-10-21 09:41:56 +08:00
if (!AllowTextual && R.getRole() & ModuleMap::TextualHeader)
[modules] Add support for 'textual header' directives. This allows a module to specify that it logically contains a file, but that said file is non-modular and intended for textual inclusion. This allows layering checks to work properly in the presence of such files. llvm-svn: 220448
2014-10-23 07:50:56 +08:00
return ModuleMap::KnownHeader();
return R;
};
[cleanup] Remove unused default argument and tidy up. The RequestingModule argument was unused and always its default value of nullptr. Also move a declaration closer to its use, and range-for'ify. llvm-svn: 239453
2015-06-10 09:37:59 +08:00
HeadersMap::iterator Known = findKnownHeader(File);
Implement support for module requirements, which indicate the language features needed for a particular module to be available. This allows mixed-language modules, where certain headers only work under some language variants (e.g., in C++, std.tuple might only be available in C++11 mode). llvm-svn: 147387
2011-12-31 12:05:44 +08:00
if (Known != Headers.end()) {
[modules] Support combining 'textual' with 'private'. llvm-svn: 220589
2014-10-25 04:23:01 +08:00
ModuleMap::KnownHeader Result;
Allow a header to be part of multiple modules. This patch changes two things: a) Allow a header to be part of multiple modules. The reasoning is that in existing codebases that have a module-like build system, the same headers might be used in several build targets. Simple reasons might be that they defined different classes that are declared in the same header. Supporting a header as a part of multiple modules will make the transistion easier for those cases. A later step in clang can then determine whether the two modules are actually compatible and can be merged and error out appropriately. The later check is similar to what needs to be done for template specializations anyway. b) Allow modules to be stored in a directory tree separate from the headers they describe. Review: http://llvm-reviews.chandlerc.com/D1951 llvm-svn: 193151
2013-10-22 16:09:47 +08:00
// Iterate over all modules that 'File' is part of to find the best fit.
[cleanup] Remove unused default argument and tidy up. The RequestingModule argument was unused and always its default value of nullptr. Also move a declaration closer to its use, and range-for'ify. llvm-svn: 239453
2015-06-10 09:37:59 +08:00
for (KnownHeader &H : Known->second) {
[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
2016-02-20 06:25:36 +08:00
// Prefer a header from the source module over all others.
if (H.getModule()->getTopLevelModule() == SourceModule)
[modules] When building a module, if there are multiple matches for a header file in the loaded module maps and one of them is from the current module, that's the right match. llvm-svn: 240350
2015-06-23 06:20:47 +08:00
return MakeResult(H);
[cleanup] Remove unused default argument and tidy up. The RequestingModule argument was unused and always its default value of nullptr. Also move a declaration closer to its use, and range-for'ify. llvm-svn: 239453
2015-06-10 09:37:59 +08:00
if (!Result || isBetterKnownHeader(H, Result))
Result = H;
Allow a header to be part of multiple modules. This patch changes two things: a) Allow a header to be part of multiple modules. The reasoning is that in existing codebases that have a module-like build system, the same headers might be used in several build targets. Simple reasons might be that they defined different classes that are declared in the same header. Supporting a header as a part of multiple modules will make the transistion easier for those cases. A later step in clang can then determine whether the two modules are actually compatible and can be merged and error out appropriately. The later check is similar to what needs to be done for template specializations anyway. b) Allow modules to be stored in a directory tree separate from the headers they describe. Review: http://llvm-reviews.chandlerc.com/D1951 llvm-svn: 193151
2013-10-22 16:09:47 +08:00
}
[modules] Add support for 'textual header' directives. This allows a module to specify that it logically contains a file, but that said file is non-modular and intended for textual inclusion. This allows layering checks to work properly in the presence of such files. llvm-svn: 220448
2014-10-23 07:50:56 +08:00
return MakeResult(Result);
Implement support for module requirements, which indicate the language features needed for a particular module to be available. This allows mixed-language modules, where certain headers only work under some language variants (e.g., in C++, std.tuple might only be available in C++11 mode). llvm-svn: 147387
2011-12-31 12:05:44 +08:00
}
When looking for the module associated with one of our magical builtin headers, speculatively load module maps. The "magical" builtin headers are the headers we provide as part of the C standard library, which typically comes from /usr/include. We essentially merge our headers into that location (due to cyclic dependencies). This change makes sure that, when header search finds one of our builtin headers, we figure out which module it actually lives in. This case is fairly rare; one ends up having to include one of the few built-in C headers we provide before including anything from /usr/include to trigger it. Fixes <rdar://problem/13787184>. llvm-svn: 180934
2013-05-03 01:58:30 +08:00
[modules] Fix HeaderFileInfo serialization to store all the known owning modules for a header, not just the current favourite. llvm-svn: 245390
2015-08-19 07:42:23 +08:00
return MakeResult(findOrCreateModuleForHeaderInUmbrellaDir(File));
}
ModuleMap::KnownHeader
ModuleMap::findOrCreateModuleForHeaderInUmbrellaDir(const FileEntry *File) {
assert(!Headers.count(File) && "already have a module for this header");
Remove useless 'llvm::' qualifier from names like StringRef and others that are brought into 'clang' namespace by clang/Basic/LLVM.h llvm-svn: 172323
2013-01-13 03:30:44 +08:00
SmallVector<const DirectoryEntry *, 2> SkippedDirs;
Move search for header in umbrella directories into its own function No functional change intended. llvm-svn: 205942
2014-04-10 08:39:10 +08:00
KnownHeader H = findHeaderInUmbrellaDirs(File, SkippedDirs);
if (H) {
Module *Result = H.getModule();
// Search up the module stack until we find a module with an umbrella
// directory.
Module *UmbrellaModule = Result;
while (!UmbrellaModule->getUmbrellaDir() && UmbrellaModule->Parent)
UmbrellaModule = UmbrellaModule->Parent;
if (UmbrellaModule->InferSubmodules) {
Refactor the module map file used for uniquing a module name out of class Module. It's almost always going to be the same as getContainingModule() for top-level modules, so just add a map to cover the remaining cases. This lets us do less bookkeeping to keep the ModuleMap fields up to date. llvm-svn: 215268
2014-08-09 08:57:23 +08:00
const FileEntry *UmbrellaModuleMap =
getModuleMapFileForUniquing(UmbrellaModule);
Move search for header in umbrella directories into its own function No functional change intended. llvm-svn: 205942
2014-04-10 08:39:10 +08:00
// Infer submodules for each of the directories we found between
// the directory of the umbrella header and the directory where
// the actual header is located.
bool Explicit = UmbrellaModule->InferExplicitSubmodules;
for (unsigned I = SkippedDirs.size(); I != 0; --I) {
// Find or create the module that corresponds to this directory name.
Sanitize the names of modules determined based on the names of headers or directories, to make sure that they are identifiers that are not keywords in any dialect. Fixes <rdar://problem/12489495>. llvm-svn: 165821
2012-10-13 05:15:50 +08:00
SmallString<32> NameBuf;
StringRef Name = sanitizeFilenameAsIdentifier(
Move search for header in umbrella directories into its own function No functional change intended. llvm-svn: 205942
2014-04-10 08:39:10 +08:00
llvm::sys::path::stem(SkippedDirs[I-1]->getName()), NameBuf);
Refactor the module map file used for uniquing a module name out of class Module. It's almost always going to be the same as getContainingModule() for top-level modules, so just add a map to cover the remaining cases. This lets us do less bookkeeping to keep the ModuleMap fields up to date. llvm-svn: 215268
2014-08-09 08:57:23 +08:00
Result = findOrCreateModule(Name, Result, /*IsFramework=*/false,
Explicit).first;
InferredModuleAllowedBy[Result] = UmbrellaModuleMap;
Do not print inferred submodules explicitly in __inferred_module.map Otherwise including a header in your source file that is not included by framework's umbrella header will silently add an empty submodule with that name. is automatically translated to @import Foo.NotInModule; which then would have succeeded because the inferred module map contained an empty submodule called NotInModule. llvm-svn: 207024
2014-04-24 05:10:46 +08:00
Result->IsInferred = true;
Move search for header in umbrella directories into its own function No functional change intended. llvm-svn: 205942
2014-04-10 08:39:10 +08:00
// Associate the module and the directory.
UmbrellaDirs[SkippedDirs[I-1]] = Result;
// If inferred submodules export everything they import, add a
Implement inferred submodules support, which (when requested) implicitly generates submodules corresponding to the headers that fall within a module. llvm-svn: 145887
2011-12-06 09:10:29 +08:00
// wildcard to the set of exports.
Minor tweak to prepare for submodules with umbrella headers. No actual functionality change yet. llvm-svn: 145938
2011-12-07 00:17:15 +08:00
if (UmbrellaModule->InferExportWildcard && Result->Exports.empty())
[C++11] Use 'nullptr'. Lex edition. llvm-svn: 209083
2014-05-18 07:10:59 +08:00
Result->Exports.push_back(Module::ExportDecl(nullptr, true));
Implement inferred submodules support, which (when requested) implicitly generates submodules corresponding to the headers that fall within a module. llvm-svn: 145887
2011-12-06 09:10:29 +08:00
}
Implement support for module requirements, which indicate the language features needed for a particular module to be available. This allows mixed-language modules, where certain headers only work under some language variants (e.g., in C++, std.tuple might only be available in C++11 mode). llvm-svn: 147387
2011-12-31 12:05:44 +08:00
Move search for header in umbrella directories into its own function No functional change intended. llvm-svn: 205942
2014-04-10 08:39:10 +08:00
// Infer a submodule with the same name as this header file.
SmallString<32> NameBuf;
StringRef Name = sanitizeFilenameAsIdentifier(
Allow multiple modules with the same name to coexist in the module cache To differentiate between two modules with the same name, we will consider the path the module map file that they are defined by* part of the ‘key’ for looking up the precompiled module (pcm file). Specifically, this patch renames the precompiled module (pcm) files from cache-path/<module hash>/Foo.pcm to cache-path/<module hash>/Foo-<hash of module map path>.pcm In addition, I’ve taught the ASTReader to re-resolve the names of imported modules during module loading so that if the header search context changes between when a module was originally built and when it is loaded we can rebuild it if necessary. For example, if module A imports module B first time: clang -I /path/to/A -I /path/to/B ... second time: clang -I /path/to/A -I /different/path/to/B ... will now rebuild A as expected. * in the case of inferred modules, we use the module map file that allowed the inference, not the __inferred_module.map file, since the inferred file path is the same for every inferred module. llvm-svn: 206201
2014-04-15 02:00:01 +08:00
llvm::sys::path::stem(File->getName()), NameBuf);
Refactor the module map file used for uniquing a module name out of class Module. It's almost always going to be the same as getContainingModule() for top-level modules, so just add a map to cover the remaining cases. This lets us do less bookkeeping to keep the ModuleMap fields up to date. llvm-svn: 215268
2014-08-09 08:57:23 +08:00
Result = findOrCreateModule(Name, Result, /*IsFramework=*/false,
Explicit).first;
InferredModuleAllowedBy[Result] = UmbrellaModuleMap;
Do not print inferred submodules explicitly in __inferred_module.map Otherwise including a header in your source file that is not included by framework's umbrella header will silently add an empty submodule with that name. is automatically translated to @import Foo.NotInModule; which then would have succeeded because the inferred module map contained an empty submodule called NotInModule. llvm-svn: 207024
2014-04-24 05:10:46 +08:00
Result->IsInferred = true;
Move search for header in umbrella directories into its own function No functional change intended. llvm-svn: 205942
2014-04-10 08:39:10 +08:00
Result->addTopHeader(File);
// If inferred submodules export everything they import, add a
// wildcard to the set of exports.
if (UmbrellaModule->InferExportWildcard && Result->Exports.empty())
[C++11] Use 'nullptr'. Lex edition. llvm-svn: 209083
2014-05-18 07:10:59 +08:00
Result->Exports.push_back(Module::ExportDecl(nullptr, true));
Move search for header in umbrella directories into its own function No functional change intended. llvm-svn: 205942
2014-04-10 08:39:10 +08:00
} else {
// Record each of the directories we stepped through as being part of
// the module we found, since the umbrella header covers them all.
for (unsigned I = 0, N = SkippedDirs.size(); I != N; ++I)
UmbrellaDirs[SkippedDirs[I]] = Result;
A module with an umbrella header assumes that all of the headers in the umbrella header's directory and its subdirectories are part of the module (that's why it's an umbrella). Make sure that these headers are considered to be part of the module for lookup purposes. llvm-svn: 144859
2011-11-17 07:02:25 +08:00
}
Move search for header in umbrella directories into its own function No functional change intended. llvm-svn: 205942
2014-04-10 08:39:10 +08:00
[modules] Fix HeaderFileInfo serialization to store all the known owning modules for a header, not just the current favourite. llvm-svn: 245390
2015-08-19 07:42:23 +08:00
KnownHeader Header(Result, NormalHeader);
Headers[File].push_back(Header);
return Header;
Move search for header in umbrella directories into its own function No functional change intended. llvm-svn: 205942
2014-04-10 08:39:10 +08:00
}
[modules] Add support for 'textual header' directives. This allows a module to specify that it logically contains a file, but that said file is non-modular and intended for textual inclusion. This allows layering checks to work properly in the presence of such files. llvm-svn: 220448
2014-10-23 07:50:56 +08:00
This patch adds new private headers to the module map. Private headers may be included from within the module, but not from outside the module. llvm-svn: 184471
2013-06-21 05:14:14 +08:00
return KnownHeader();
Wire up the mapping from header files mentioned in module maps over to the corresponding (top-level) modules. This isn't actually useful yet, because we don't yet have a way to build modules out of module maps. llvm-svn: 144410
2011-11-12 06:18:48 +08:00
}
[modules] Fix HeaderFileInfo serialization to store all the known owning modules for a header, not just the current favourite. llvm-svn: 245390
2015-08-19 07:42:23 +08:00
ArrayRef<ModuleMap::KnownHeader>
ModuleMap::findAllModulesForHeader(const FileEntry *File) const {
auto It = Headers.find(File);
if (It == Headers.end())
return None;
return It->second;
}
[modules] Const'ify some functions of ModuleMap. llvm-svn: 175552
2013-02-20 03:58:45 +08:00
bool ModuleMap::isHeaderInUnavailableModule(const FileEntry *Header) const {
[C++11] Use 'nullptr'. Lex edition. llvm-svn: 209083
2014-05-18 07:10:59 +08:00
return isHeaderUnavailableInModule(Header, nullptr);
If a header is explicitly included in module A, and excluded from an umbrella directory in module B, don't include it in module B! llvm-svn: 205762
2014-04-08 21:13:04 +08:00
}
Add more constness to module-related APIs llvm-svn: 206595
2014-04-18 22:36:51 +08:00
bool
ModuleMap::isHeaderUnavailableInModule(const FileEntry *Header,
const Module *RequestingModule) const {
[modules] Const'ify some functions of ModuleMap. llvm-svn: 175552
2013-02-20 03:58:45 +08:00
HeadersMap::const_iterator Known = Headers.find(Header);
Allow a header to be part of multiple modules. This patch changes two things: a) Allow a header to be part of multiple modules. The reasoning is that in existing codebases that have a module-like build system, the same headers might be used in several build targets. Simple reasons might be that they defined different classes that are declared in the same header. Supporting a header as a part of multiple modules will make the transistion easier for those cases. A later step in clang can then determine whether the two modules are actually compatible and can be merged and error out appropriately. The later check is similar to what needs to be done for template specializations anyway. b) Allow modules to be stored in a directory tree separate from the headers they describe. Review: http://llvm-reviews.chandlerc.com/D1951 llvm-svn: 193151
2013-10-22 16:09:47 +08:00
if (Known != Headers.end()) {
for (SmallVectorImpl<KnownHeader>::const_iterator
I = Known->second.begin(),
E = Known->second.end();
I != E; ++I) {
If a header is explicitly included in module A, and excluded from an umbrella directory in module B, don't include it in module B! llvm-svn: 205762
2014-04-08 21:13:04 +08:00
if (I->isAvailable() && (!RequestingModule ||
I->getModule()->isSubModuleOf(RequestingModule)))
Allow a header to be part of multiple modules. This patch changes two things: a) Allow a header to be part of multiple modules. The reasoning is that in existing codebases that have a module-like build system, the same headers might be used in several build targets. Simple reasons might be that they defined different classes that are declared in the same header. Supporting a header as a part of multiple modules will make the transistion easier for those cases. A later step in clang can then determine whether the two modules are actually compatible and can be merged and error out appropriately. The later check is similar to what needs to be done for template specializations anyway. b) Allow modules to be stored in a directory tree separate from the headers they describe. Review: http://llvm-reviews.chandlerc.com/D1951 llvm-svn: 193151
2013-10-22 16:09:47 +08:00
return false;
}
return true;
}
If a header is explicitly included in module A, and excluded from an umbrella directory in module B, don't include it in module B! llvm-svn: 205762
2014-04-08 21:13:04 +08:00
Implement support for module requirements, which indicate the language features needed for a particular module to be available. This allows mixed-language modules, where certain headers only work under some language variants (e.g., in C++, std.tuple might only be available in C++11 mode). llvm-svn: 147387
2011-12-31 12:05:44 +08:00
const DirectoryEntry *Dir = Header->getDir();
Remove useless 'llvm::' qualifier from names like StringRef and others that are brought into 'clang' namespace by clang/Basic/LLVM.h llvm-svn: 172323
2013-01-13 03:30:44 +08:00
SmallVector<const DirectoryEntry *, 2> SkippedDirs;
Implement support for module requirements, which indicate the language features needed for a particular module to be available. This allows mixed-language modules, where certain headers only work under some language variants (e.g., in C++, std.tuple might only be available in C++11 mode). llvm-svn: 147387
2011-12-31 12:05:44 +08:00
StringRef DirName = Dir->getName();
If a header is explicitly included in module A, and excluded from an umbrella directory in module B, don't include it in module B! llvm-svn: 205762
2014-04-08 21:13:04 +08:00
auto IsUnavailable = [&](const Module *M) {
return !M->isAvailable() && (!RequestingModule ||
M->isSubModuleOf(RequestingModule));
};
Implement support for module requirements, which indicate the language features needed for a particular module to be available. This allows mixed-language modules, where certain headers only work under some language variants (e.g., in C++, std.tuple might only be available in C++11 mode). llvm-svn: 147387
2011-12-31 12:05:44 +08:00
// Keep walking up the directory hierarchy, looking for a directory with
// an umbrella header.
If a header is explicitly included in module A, and excluded from an umbrella directory in module B, don't include it in module B! llvm-svn: 205762
2014-04-08 21:13:04 +08:00
do {
[modules] Const'ify some functions of ModuleMap. llvm-svn: 175552
2013-02-20 03:58:45 +08:00
llvm::DenseMap<const DirectoryEntry *, Module *>::const_iterator KnownDir
Implement support for module requirements, which indicate the language features needed for a particular module to be available. This allows mixed-language modules, where certain headers only work under some language variants (e.g., in C++, std.tuple might only be available in C++11 mode). llvm-svn: 147387
2011-12-31 12:05:44 +08:00
= UmbrellaDirs.find(Dir);
if (KnownDir != UmbrellaDirs.end()) {
Module *Found = KnownDir->second;
If a header is explicitly included in module A, and excluded from an umbrella directory in module B, don't include it in module B! llvm-svn: 205762
2014-04-08 21:13:04 +08:00
if (IsUnavailable(Found))
Implement support for module requirements, which indicate the language features needed for a particular module to be available. This allows mixed-language modules, where certain headers only work under some language variants (e.g., in C++, std.tuple might only be available in C++11 mode). llvm-svn: 147387
2011-12-31 12:05:44 +08:00
return true;
// Search up the module stack until we find a module with an umbrella
// directory.
Module *UmbrellaModule = Found;
while (!UmbrellaModule->getUmbrellaDir() && UmbrellaModule->Parent)
UmbrellaModule = UmbrellaModule->Parent;
if (UmbrellaModule->InferSubmodules) {
for (unsigned I = SkippedDirs.size(); I != 0; --I) {
// Find or create the module that corresponds to this directory name.
Sanitize the names of modules determined based on the names of headers or directories, to make sure that they are identifiers that are not keywords in any dialect. Fixes <rdar://problem/12489495>. llvm-svn: 165821
2012-10-13 05:15:50 +08:00
SmallString<32> NameBuf;
StringRef Name = sanitizeFilenameAsIdentifier(
llvm::sys::path::stem(SkippedDirs[I-1]->getName()),
NameBuf);
Implement support for module requirements, which indicate the language features needed for a particular module to be available. This allows mixed-language modules, where certain headers only work under some language variants (e.g., in C++, std.tuple might only be available in C++11 mode). llvm-svn: 147387
2011-12-31 12:05:44 +08:00
Found = lookupModuleQualified(Name, Found);
if (!Found)
return false;
If a header is explicitly included in module A, and excluded from an umbrella directory in module B, don't include it in module B! llvm-svn: 205762
2014-04-08 21:13:04 +08:00
if (IsUnavailable(Found))
Implement support for module requirements, which indicate the language features needed for a particular module to be available. This allows mixed-language modules, where certain headers only work under some language variants (e.g., in C++, std.tuple might only be available in C++11 mode). llvm-svn: 147387
2011-12-31 12:05:44 +08:00
return true;
}
// Infer a submodule with the same name as this header file.
Sanitize the names of modules determined based on the names of headers or directories, to make sure that they are identifiers that are not keywords in any dialect. Fixes <rdar://problem/12489495>. llvm-svn: 165821
2012-10-13 05:15:50 +08:00
SmallString<32> NameBuf;
StringRef Name = sanitizeFilenameAsIdentifier(
llvm::sys::path::stem(Header->getName()),
NameBuf);
Implement support for module requirements, which indicate the language features needed for a particular module to be available. This allows mixed-language modules, where certain headers only work under some language variants (e.g., in C++, std.tuple might only be available in C++11 mode). llvm-svn: 147387
2011-12-31 12:05:44 +08:00
Found = lookupModuleQualified(Name, Found);
if (!Found)
return false;
}
If a header is explicitly included in module A, and excluded from an umbrella directory in module B, don't include it in module B! llvm-svn: 205762
2014-04-08 21:13:04 +08:00
return IsUnavailable(Found);
Implement support for module requirements, which indicate the language features needed for a particular module to be available. This allows mixed-language modules, where certain headers only work under some language variants (e.g., in C++, std.tuple might only be available in C++11 mode). llvm-svn: 147387
2011-12-31 12:05:44 +08:00
}
SkippedDirs.push_back(Dir);
// Retrieve our parent path.
DirName = llvm::sys::path::parent_path(DirName);
if (DirName.empty())
break;
// Resolve the parent path to a directory entry.
Use the same SourceManager for ModuleMaps and compilations. This allows using virtual file mappings on the original SourceManager to map in virtual module.map files. Without this patch, the ModuleMap search will find a module.map file (as the FileEntry exists in the FileManager), but will be unable to get the content from the SourceManager (as ModuleMap previously created its own SourceManager). Two problems needed to be fixed which this patch exposed: 1. Storing the inferred module map When writing out a module, the ASTWriter stores the names of the files in the main source manager; when loading the AST again, the ASTReader errs out if such a file is found missing, unless it is overridden. Previously CompilerInstance's compileModule method would store the inferred module map to a temporary file; the problem with this approach is that now that the module map is handled by the main source manager, the ASTWriter stores the name of the temporary module map as source to the compilation; later, when the module is loaded, the temporary file has already been deleted, which leads to a compilation error. This patch changes the inferred module map to instead inject a virtual file into the source manager. This both saves some disk IO, and works with how the ASTWriter/ASTReader handle overridden source files. 2. Changing test input in test/Modules/Inputs/* Now that the module map file is handled by the main source manager, the VerifyDiagnosticConsumer will not ignore diagnostics created while parsing the module map file. The module test test/Modules/renamed.m uses -I test/Modules/Inputs and triggers recursive loading of all module maps in test/Modules/Inputs, some of which had conflicting names, thus leading errors while parsing the module maps. Those diagnostics already occur on trunk, but before this patch they would not break the test, as they were ignored by the VerifyDiagnosticConsumer. This patch thus changes the module maps that have been recently introduced which broke the invariant of compatible modules maps in test/Modules/Inputs. llvm-svn: 193314
2013-10-24 15:51:24 +08:00
Dir = SourceMgr.getFileManager().getDirectory(DirName);
Implement support for module requirements, which indicate the language features needed for a particular module to be available. This allows mixed-language modules, where certain headers only work under some language variants (e.g., in C++, std.tuple might only be available in C++11 mode). llvm-svn: 147387
2011-12-31 12:05:44 +08:00
} while (Dir);
return false;
}
[modules] Const'ify some functions of ModuleMap. llvm-svn: 175552
2013-02-20 03:58:45 +08:00
Module *ModuleMap::findModule(StringRef Name) const {
llvm::StringMap<Module *>::const_iterator Known = Modules.find(Name);
Teach the search for modules to consider modules described by a module map, so long as they have an umbrella header. This makes it possible to introduce a module map + umbrella header for a given set of headers, to turn it into a module. There are two major deficiencies here: first, we don't go hunting for module map files when we just see a module import (so we won't know about the modules described therein). Second, we don't yet have a way to build modules that don't have umbrella headers, or have incomplete umbrella headers. llvm-svn: 144424
2011-11-12 07:20:24 +08:00
if (Known != Modules.end())
return Known->getValue();
[C++11] Use 'nullptr'. Lex edition. llvm-svn: 209083
2014-05-18 07:10:59 +08:00
return nullptr;
Teach the search for modules to consider modules described by a module map, so long as they have an umbrella header. This makes it possible to introduce a module map + umbrella header for a given set of headers, to turn it into a module. There are two major deficiencies here: first, we don't go hunting for module map files when we just see a module import (so we won't know about the modules described therein). Second, we don't yet have a way to build modules that don't have umbrella headers, or have incomplete umbrella headers. llvm-svn: 144424
2011-11-12 07:20:24 +08:00
}
[modules] Const'ify some functions of ModuleMap. llvm-svn: 175552
2013-02-20 03:58:45 +08:00
Module *ModuleMap::lookupModuleUnqualified(StringRef Name,
Module *Context) const {
Implementing parsing and resolution of module export declarations within module maps, which will (eventually) be used to re-export a module from another module. There are still some pieces missing, however. llvm-svn: 145665
2011-12-02 09:47:07 +08:00
for(; Context; Context = Context->Parent) {
if (Module *Sub = lookupModuleQualified(Name, Context))
return Sub;
}
return findModule(Name);
}
[modules] Const'ify some functions of ModuleMap. llvm-svn: 175552
2013-02-20 03:58:45 +08:00
Module *ModuleMap::lookupModuleQualified(StringRef Name, Module *Context) const{
Implementing parsing and resolution of module export declarations within module maps, which will (eventually) be used to re-export a module from another module. There are still some pieces missing, however. llvm-svn: 145665
2011-12-02 09:47:07 +08:00
if (!Context)
return findModule(Name);
Store the submodules of a module in source order, as they are stored in the module map. This provides a bit more predictability for the user, as well as eliminating the need to sort the submodules when serializing them. llvm-svn: 147564
2012-01-05 07:32:19 +08:00
return Context->findSubmodule(Name);
Implementing parsing and resolution of module export declarations within module maps, which will (eventually) be used to re-export a module from another module. There are still some pieces missing, however. llvm-svn: 145665
2011-12-02 09:47:07 +08:00
}
Promote ModuleMap::Module to a namespace-scope class in the Basic library, since modules cut across all of the libraries. Rename serialization::Module to serialization::ModuleFile to side-step the annoying naming conflict. Prune a bunch of ModuleMap.h includes that are no longer needed (most files only needed the Module type). llvm-svn: 145538
2011-12-01 07:21:26 +08:00
std::pair<Module *, bool>
Refactor the module map file used for uniquing a module name out of class Module. It's almost always going to be the same as getContainingModule() for top-level modules, so just add a map to cover the remaining cases. This lets us do less bookkeeping to keep the ModuleMap fields up to date. llvm-svn: 215268
2014-08-09 08:57:23 +08:00
ModuleMap::findOrCreateModule(StringRef Name, Module *Parent, bool IsFramework,
Implement (de-)serialization of the description of a module and its submodules. This information will eventually be used for name hiding when dealing with submodules. For now, we only use it to ensure that the module "key" returned when loading a module will always be a module (rather than occasionally being a FileEntry). llvm-svn: 145497
2011-12-01 01:33:56 +08:00
bool IsExplicit) {
// Try to find an existing module with this name.
Store the submodules of a module in source order, as they are stored in the module map. This provides a bit more predictability for the user, as well as eliminating the need to sort the submodules when serializing them. llvm-svn: 147564
2012-01-05 07:32:19 +08:00
if (Module *Sub = lookupModuleQualified(Name, Parent))
return std::make_pair(Sub, false);
Implement (de-)serialization of the description of a module and its submodules. This information will eventually be used for name hiding when dealing with submodules. For now, we only use it to ensure that the module "key" returned when loading a module will always be a module (rather than occasionally being a FileEntry). llvm-svn: 145497
2011-12-01 01:33:56 +08:00
// Create a new module with this name.
Refactor the module map file used for uniquing a module name out of class Module. It's almost always going to be the same as getContainingModule() for top-level modules, so just add a map to cover the remaining cases. This lets us do less bookkeeping to keep the ModuleMap fields up to date. llvm-svn: 215268
2014-08-09 08:57:23 +08:00
Module *Result = new Module(Name, SourceLocation(), Parent,
[modules] Start moving the module visibility information off the Module itself. 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. llvm-svn: 236300
2015-05-01 09:53:09 +08:00
IsFramework, IsExplicit, NumCreatedModules++);
[modules] When building a module, make sure we don't serialize out HeaderFileInfo for headers not belonging to the module. After r180934 we may initiate module map parsing for modules not related to the module what we are building, make sure we ignore the header file info of headers from such modules. First part of rdar://13840148 llvm-svn: 181489
2013-05-09 07:46:46 +08:00
if (!Parent) {
[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
2016-02-20 06:25:36 +08:00
if (LangOpts.CurrentModule == Name)
SourceModule = Result;
Implement (de-)serialization of the description of a module and its submodules. This information will eventually be used for name hiding when dealing with submodules. For now, we only use it to ensure that the module "key" returned when loading a module will always be a module (rather than occasionally being a FileEntry). llvm-svn: 145497
2011-12-01 01:33:56 +08:00
Modules[Name] = Result;
[modules] When building a module, make sure we don't serialize out HeaderFileInfo for headers not belonging to the module. After r180934 we may initiate module map parsing for modules not related to the module what we are building, make sure we ignore the header file info of headers from such modules. First part of rdar://13840148 llvm-svn: 181489
2013-05-09 07:46:46 +08:00
}
Implement (de-)serialization of the description of a module and its submodules. This information will eventually be used for name hiding when dealing with submodules. For now, we only use it to ensure that the module "key" returned when loading a module will always be a module (rather than occasionally being a FileEntry). llvm-svn: 145497
2011-12-01 01:33:56 +08:00
return std::make_pair(Result, true);
}
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
2016-08-26 08:14:38 +08:00
Module *ModuleMap::createModuleForInterfaceUnit(SourceLocation Loc,
StringRef Name) {
assert(LangOpts.CurrentModule == Name && "module name mismatch");
assert(!Modules[Name] && "redefining existing module");
auto *Result =
new Module(Name, Loc, nullptr, /*IsFramework*/ false,
/*IsExplicit*/ false, NumCreatedModules++);
Modules[Name] = SourceModule = Result;
// Mark the main source file as being within the newly-created module so that
// declarations and macros are properly visibility-restricted to it.
auto *MainFile = SourceMgr.getFileEntryForID(SourceMgr.getMainFileID());
assert(MainFile && "no input file for module interface");
Headers[MainFile].push_back(KnownHeader(Result, PrivateHeader));
return Result;
}
Infer "link" lines for top-level frameworks. Essentially, a framework will have a shared library with the same name as its framework (and no suffix!) within its .framework directory. Detect this both when inferring the whole top-level framework and when parsing a module map. llvm-svn: 172439
2013-01-15 01:57:51 +08:00
/// \brief For a framework module, infer the framework against which we
/// should link.
static void inferFrameworkLink(Module *Mod, const DirectoryEntry *FrameworkDir,
FileManager &FileMgr) {
assert(Mod->IsFramework && "Can only infer linking for framework modules");
assert(!Mod->isSubFramework() &&
"Can only infer linking for top-level frameworks");
SmallString<128> LibName;
LibName += FrameworkDir->getName();
llvm::sys::path::append(LibName, Mod->Name);
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
2015-11-14 03:08:07 +08:00
// The library name of a framework has more than one possible extension since
// the introduction of the text-based dynamic library format. We need to check
// for both before we give up.
[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
2016-11-16 02:56:39 +08:00
for (const char *extension : {"", ".tbd"}) {
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
2015-11-14 03:08:07 +08:00
llvm::sys::path::replace_extension(LibName, extension);
if (FileMgr.getFile(LibName)) {
Mod->LinkLibraries.push_back(Module::LinkLibrary(Mod->Name,
/*IsFramework=*/true));
return;
}
Infer "link" lines for top-level frameworks. Essentially, a framework will have a shared library with the same name as its framework (and no suffix!) within its .framework directory. Detect this both when inferring the whole top-level framework and when parsing a module map. llvm-svn: 172439
2013-01-15 01:57:51 +08:00
}
}
[Modules] Be consistent about finding a module for framework headers 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 llvm-svn: 241258
2015-07-02 21:19:48 +08:00
Module *ModuleMap::inferFrameworkModule(const DirectoryEntry *FrameworkDir,
bool IsSystem, Module *Parent) {
Inherit attributes when infering a framework module If a module map contains framework module * [extern_c] {} We will now infer [extern_c] on the inferred framework modules (we already inferred [system] as a special case). llvm-svn: 225803
2015-01-14 01:47:44 +08:00
Attributes Attrs;
Attrs.IsSystem = IsSystem;
[Modules] Be consistent about finding a module for framework headers 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 llvm-svn: 241258
2015-07-02 21:19:48 +08:00
return inferFrameworkModule(FrameworkDir, Attrs, Parent);
Inherit attributes when infering a framework module If a module map contains framework module * [extern_c] {} We will now infer [extern_c] on the inferred framework modules (we already inferred [system] as a special case). llvm-svn: 225803
2015-01-14 01:47:44 +08:00
}
[Modules] Be consistent about finding a module for framework headers 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 llvm-svn: 241258
2015-07-02 21:19:48 +08:00
Module *ModuleMap::inferFrameworkModule(const DirectoryEntry *FrameworkDir,
Inherit attributes when infering a framework module If a module map contains framework module * [extern_c] {} We will now infer [extern_c] on the inferred framework modules (we already inferred [system] as a special case). llvm-svn: 225803
2015-01-14 01:47:44 +08:00
Attributes Attrs, Module *Parent) {
[Modules] Be consistent about finding a module for framework headers 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 llvm-svn: 241258
2015-07-02 21:19:48 +08:00
// Note: as an egregious but useful hack we use the real path here, because
// we might be looking at an embedded framework that symlinks out to a
// top-level framework, and we need to infer as if we were naming the
// top-level framework.
StringRef FrameworkDirName =
SourceMgr.getFileManager().getCanonicalName(FrameworkDir);
// In case this is a case-insensitive filesystem, use the canonical
// directory name as the ModuleName, since modules are case-sensitive.
// FIXME: we should be able to give a fix-it hint for the correct spelling.
SmallString<32> ModuleNameStorage;
StringRef ModuleName = sanitizeFilenameAsIdentifier(
llvm::sys::path::stem(FrameworkDirName), ModuleNameStorage);
Inherit attributes when infering a framework module If a module map contains framework module * [extern_c] {} We will now infer [extern_c] on the inferred framework modules (we already inferred [system] as a special case). llvm-svn: 225803
2015-01-14 01:47:44 +08:00
When we're loading a framework header, first try to turn the framework into a module. This module can either be loaded from a module map in the framework directory (which isn't quite working yet) or inferred from an umbrella header (which does work, and replaces the existing hack). llvm-svn: 144877
2011-11-17 09:41:17 +08:00
// Check whether we've already found this module.
When inferring a module map for a framework, infer subframework modules for each of its subframeworks. llvm-svn: 145957
2011-12-07 03:39:29 +08:00
if (Module *Mod = lookupModuleQualified(ModuleName, Parent))
return Mod;
Use the same SourceManager for ModuleMaps and compilations. This allows using virtual file mappings on the original SourceManager to map in virtual module.map files. Without this patch, the ModuleMap search will find a module.map file (as the FileEntry exists in the FileManager), but will be unable to get the content from the SourceManager (as ModuleMap previously created its own SourceManager). Two problems needed to be fixed which this patch exposed: 1. Storing the inferred module map When writing out a module, the ASTWriter stores the names of the files in the main source manager; when loading the AST again, the ASTReader errs out if such a file is found missing, unless it is overridden. Previously CompilerInstance's compileModule method would store the inferred module map to a temporary file; the problem with this approach is that now that the module map is handled by the main source manager, the ASTWriter stores the name of the temporary module map as source to the compilation; later, when the module is loaded, the temporary file has already been deleted, which leads to a compilation error. This patch changes the inferred module map to instead inject a virtual file into the source manager. This both saves some disk IO, and works with how the ASTWriter/ASTReader handle overridden source files. 2. Changing test input in test/Modules/Inputs/* Now that the module map file is handled by the main source manager, the VerifyDiagnosticConsumer will not ignore diagnostics created while parsing the module map file. The module test test/Modules/renamed.m uses -I test/Modules/Inputs and triggers recursive loading of all module maps in test/Modules/Inputs, some of which had conflicting names, thus leading errors while parsing the module maps. Those diagnostics already occur on trunk, but before this patch they would not break the test, as they were ignored by the VerifyDiagnosticConsumer. This patch thus changes the module maps that have been recently introduced which broke the invariant of compatible modules maps in test/Modules/Inputs. llvm-svn: 193314
2013-10-24 15:51:24 +08:00
FileManager &FileMgr = SourceMgr.getFileManager();
Introduce inferred framework modules into the module map file, allowing a module map to be placed one level above the '.framework' directories to specify that all .frameworks within that directory can be inferred as framework modules. One can also specifically exclude frameworks known not to work. This makes explicit (and more restricted) behavior modules have had "forever", where *any* .framework was assumed to be able to be built as a module. That's not necessarily true, so we white-list directories (with exclusions) when those directories have been audited. llvm-svn: 167482
2012-11-07 03:39:40 +08:00
// If the framework has a parent path from which we're allowed to infer
// a framework module, do so.
Allow multiple modules with the same name to coexist in the module cache To differentiate between two modules with the same name, we will consider the path the module map file that they are defined by* part of the ‘key’ for looking up the precompiled module (pcm file). Specifically, this patch renames the precompiled module (pcm) files from cache-path/<module hash>/Foo.pcm to cache-path/<module hash>/Foo-<hash of module map path>.pcm In addition, I’ve taught the ASTReader to re-resolve the names of imported modules during module loading so that if the header search context changes between when a module was originally built and when it is loaded we can rebuild it if necessary. For example, if module A imports module B first time: clang -I /path/to/A -I /path/to/B ... second time: clang -I /path/to/A -I /different/path/to/B ... will now rebuild A as expected. * in the case of inferred modules, we use the module map file that allowed the inference, not the __inferred_module.map file, since the inferred file path is the same for every inferred module. llvm-svn: 206201
2014-04-15 02:00:01 +08:00
const FileEntry *ModuleMapFile = nullptr;
Introduce inferred framework modules into the module map file, allowing a module map to be placed one level above the '.framework' directories to specify that all .frameworks within that directory can be inferred as framework modules. One can also specifically exclude frameworks known not to work. This makes explicit (and more restricted) behavior modules have had "forever", where *any* .framework was assumed to be able to be built as a module. That's not necessarily true, so we white-list directories (with exclusions) when those directories have been audited. llvm-svn: 167482
2012-11-07 03:39:40 +08:00
if (!Parent) {
Rework the realpath nonsense for framework lookups to deal more uniformly with symlinks between top-level and embedded frameworks. llvm-svn: 172030
2013-01-10 09:43:00 +08:00
// Determine whether we're allowed to infer a module map.
Introduce inferred framework modules into the module map file, allowing a module map to be placed one level above the '.framework' directories to specify that all .frameworks within that directory can be inferred as framework modules. One can also specifically exclude frameworks known not to work. This makes explicit (and more restricted) behavior modules have had "forever", where *any* .framework was assumed to be able to be built as a module. That's not necessarily true, so we white-list directories (with exclusions) when those directories have been audited. llvm-svn: 167482
2012-11-07 03:39:40 +08:00
bool canInfer = false;
Rework the realpath nonsense for framework lookups to deal more uniformly with symlinks between top-level and embedded frameworks. llvm-svn: 172030
2013-01-10 09:43:00 +08:00
if (llvm::sys::path::has_parent_path(FrameworkDirName)) {
Introduce inferred framework modules into the module map file, allowing a module map to be placed one level above the '.framework' directories to specify that all .frameworks within that directory can be inferred as framework modules. One can also specifically exclude frameworks known not to work. This makes explicit (and more restricted) behavior modules have had "forever", where *any* .framework was assumed to be able to be built as a module. That's not necessarily true, so we white-list directories (with exclusions) when those directories have been audited. llvm-svn: 167482
2012-11-07 03:39:40 +08:00
// Figure out the parent path.
Rework the realpath nonsense for framework lookups to deal more uniformly with symlinks between top-level and embedded frameworks. llvm-svn: 172030
2013-01-10 09:43:00 +08:00
StringRef Parent = llvm::sys::path::parent_path(FrameworkDirName);
Introduce inferred framework modules into the module map file, allowing a module map to be placed one level above the '.framework' directories to specify that all .frameworks within that directory can be inferred as framework modules. One can also specifically exclude frameworks known not to work. This makes explicit (and more restricted) behavior modules have had "forever", where *any* .framework was assumed to be able to be built as a module. That's not necessarily true, so we white-list directories (with exclusions) when those directories have been audited. llvm-svn: 167482
2012-11-07 03:39:40 +08:00
if (const DirectoryEntry *ParentDir = FileMgr.getDirectory(Parent)) {
// Check whether we have already looked into the parent directory
// for a module map.
[modules] Const'ify some functions of ModuleMap. llvm-svn: 175552
2013-02-20 03:58:45 +08:00
llvm::DenseMap<const DirectoryEntry *, InferredDirectory>::const_iterator
Introduce inferred framework modules into the module map file, allowing a module map to be placed one level above the '.framework' directories to specify that all .frameworks within that directory can be inferred as framework modules. One can also specifically exclude frameworks known not to work. This makes explicit (and more restricted) behavior modules have had "forever", where *any* .framework was assumed to be able to be built as a module. That's not necessarily true, so we white-list directories (with exclusions) when those directories have been audited. llvm-svn: 167482
2012-11-07 03:39:40 +08:00
inferred = InferredDirectories.find(ParentDir);
if (inferred == InferredDirectories.end()) {
// We haven't looked here before. Load a module map, if there is
// one.
Add a new spelling for module map files 'module.modulemap' This name, while more verbose, plays more nicely with tools that use file extensions to determine file types. The existing spelling 'module.map' will continue to work, but the new spelling will take precedence. In frameworks, this new filename will only go in a new 'Modules' sub-directory. Similarly, add a module.private.modulemap corresponding to module_private.map. llvm-svn: 204261
2014-03-20 04:23:34 +08:00
bool IsFrameworkDir = Parent.endswith(".framework");
if (const FileEntry *ModMapFile =
HeaderInfo.lookupModuleMapFile(ParentDir, IsFrameworkDir)) {
Inherit attributes when infering a framework module If a module map contains framework module * [extern_c] {} We will now infer [extern_c] on the inferred framework modules (we already inferred [system] as a special case). llvm-svn: 225803
2015-01-14 01:47:44 +08:00
parseModuleMapFile(ModMapFile, Attrs.IsSystem, ParentDir);
Introduce inferred framework modules into the module map file, allowing a module map to be placed one level above the '.framework' directories to specify that all .frameworks within that directory can be inferred as framework modules. One can also specifically exclude frameworks known not to work. This makes explicit (and more restricted) behavior modules have had "forever", where *any* .framework was assumed to be able to be built as a module. That's not necessarily true, so we white-list directories (with exclusions) when those directories have been audited. llvm-svn: 167482
2012-11-07 03:39:40 +08:00
inferred = InferredDirectories.find(ParentDir);
}
if (inferred == InferredDirectories.end())
inferred = InferredDirectories.insert(
std::make_pair(ParentDir, InferredDirectory())).first;
}
if (inferred->second.InferModules) {
// We're allowed to infer for this directory, but make sure it's okay
// to infer this particular module.
Rework the realpath nonsense for framework lookups to deal more uniformly with symlinks between top-level and embedded frameworks. llvm-svn: 172030
2013-01-10 09:43:00 +08:00
StringRef Name = llvm::sys::path::stem(FrameworkDirName);
Introduce inferred framework modules into the module map file, allowing a module map to be placed one level above the '.framework' directories to specify that all .frameworks within that directory can be inferred as framework modules. One can also specifically exclude frameworks known not to work. This makes explicit (and more restricted) behavior modules have had "forever", where *any* .framework was assumed to be able to be built as a module. That's not necessarily true, so we white-list directories (with exclusions) when those directories have been audited. llvm-svn: 167482
2012-11-07 03:39:40 +08:00
canInfer = std::find(inferred->second.ExcludedModules.begin(),
inferred->second.ExcludedModules.end(),
Name) == inferred->second.ExcludedModules.end();
Inherit attributes when infering a framework module If a module map contains framework module * [extern_c] {} We will now infer [extern_c] on the inferred framework modules (we already inferred [system] as a special case). llvm-svn: 225803
2015-01-14 01:47:44 +08:00
Attrs.IsSystem |= inferred->second.Attrs.IsSystem;
Attrs.IsExternC |= inferred->second.Attrs.IsExternC;
Attrs.IsExhaustive |= inferred->second.Attrs.IsExhaustive;
[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
2016-10-21 09:41:56 +08:00
Attrs.NoUndeclaredIncludes |=
inferred->second.Attrs.NoUndeclaredIncludes;
Allow multiple modules with the same name to coexist in the module cache To differentiate between two modules with the same name, we will consider the path the module map file that they are defined by* part of the ‘key’ for looking up the precompiled module (pcm file). Specifically, this patch renames the precompiled module (pcm) files from cache-path/<module hash>/Foo.pcm to cache-path/<module hash>/Foo-<hash of module map path>.pcm In addition, I’ve taught the ASTReader to re-resolve the names of imported modules during module loading so that if the header search context changes between when a module was originally built and when it is loaded we can rebuild it if necessary. For example, if module A imports module B first time: clang -I /path/to/A -I /path/to/B ... second time: clang -I /path/to/A -I /different/path/to/B ... will now rebuild A as expected. * in the case of inferred modules, we use the module map file that allowed the inference, not the __inferred_module.map file, since the inferred file path is the same for every inferred module. llvm-svn: 206201
2014-04-15 02:00:01 +08:00
ModuleMapFile = inferred->second.ModuleMapFile;
Introduce inferred framework modules into the module map file, allowing a module map to be placed one level above the '.framework' directories to specify that all .frameworks within that directory can be inferred as framework modules. One can also specifically exclude frameworks known not to work. This makes explicit (and more restricted) behavior modules have had "forever", where *any* .framework was assumed to be able to be built as a module. That's not necessarily true, so we white-list directories (with exclusions) when those directories have been audited. llvm-svn: 167482
2012-11-07 03:39:40 +08:00
}
}
}
// If we're not allowed to infer a framework module, don't.
if (!canInfer)
[C++11] Use 'nullptr'. Lex edition. llvm-svn: 209083
2014-05-18 07:10:59 +08:00
return nullptr;
Allow multiple modules with the same name to coexist in the module cache To differentiate between two modules with the same name, we will consider the path the module map file that they are defined by* part of the ‘key’ for looking up the precompiled module (pcm file). Specifically, this patch renames the precompiled module (pcm) files from cache-path/<module hash>/Foo.pcm to cache-path/<module hash>/Foo-<hash of module map path>.pcm In addition, I’ve taught the ASTReader to re-resolve the names of imported modules during module loading so that if the header search context changes between when a module was originally built and when it is loaded we can rebuild it if necessary. For example, if module A imports module B first time: clang -I /path/to/A -I /path/to/B ... second time: clang -I /path/to/A -I /different/path/to/B ... will now rebuild A as expected. * in the case of inferred modules, we use the module map file that allowed the inference, not the __inferred_module.map file, since the inferred file path is the same for every inferred module. llvm-svn: 206201
2014-04-15 02:00:01 +08:00
} else
Refactor the module map file used for uniquing a module name out of class Module. It's almost always going to be the same as getContainingModule() for top-level modules, so just add a map to cover the remaining cases. This lets us do less bookkeeping to keep the ModuleMap fields up to date. llvm-svn: 215268
2014-08-09 08:57:23 +08:00
ModuleMapFile = getModuleMapFileForUniquing(Parent);
Introduce inferred framework modules into the module map file, allowing a module map to be placed one level above the '.framework' directories to specify that all .frameworks within that directory can be inferred as framework modules. One can also specifically exclude frameworks known not to work. This makes explicit (and more restricted) behavior modules have had "forever", where *any* .framework was assumed to be able to be built as a module. That's not necessarily true, so we white-list directories (with exclusions) when those directories have been audited. llvm-svn: 167482
2012-11-07 03:39:40 +08:00
When we're loading a framework header, first try to turn the framework into a module. This module can either be loaded from a module map in the framework directory (which isn't quite working yet) or inferred from an umbrella header (which does work, and replaces the existing hack). llvm-svn: 144877
2011-11-17 09:41:17 +08:00
// Look for an umbrella header.
Basic: import SmallString<> into clang namespace (I was going to fix the TODO about DenseMap too, but that would break self-host right now. See PR11922.) llvm-svn: 149799
2012-02-05 10:13:05 +08:00
SmallString<128> UmbrellaName = StringRef(FrameworkDir->getName());
Use the multiple argument form of path::append. llvm-svn: 185164
2013-06-29 00:25:46 +08:00
llvm::sys::path::append(UmbrellaName, "Headers", ModuleName + ".h");
When inferring a module map for a framework, infer subframework modules for each of its subframeworks. llvm-svn: 145957
2011-12-07 03:39:29 +08:00
const FileEntry *UmbrellaHeader = FileMgr.getFile(UmbrellaName);
When we're loading a framework header, first try to turn the framework into a module. This module can either be loaded from a module map in the framework directory (which isn't quite working yet) or inferred from an umbrella header (which does work, and replaces the existing hack). llvm-svn: 144877
2011-11-17 09:41:17 +08:00
// FIXME: If there's no umbrella header, we could probably scan the
// framework to load *everything*. But, it's not clear that this is a good
// idea.
if (!UmbrellaHeader)
[C++11] Use 'nullptr'. Lex edition. llvm-svn: 209083
2014-05-18 07:10:59 +08:00
return nullptr;
Refactor the module map file used for uniquing a module name out of class Module. It's almost always going to be the same as getContainingModule() for top-level modules, so just add a map to cover the remaining cases. This lets us do less bookkeeping to keep the ModuleMap fields up to date. llvm-svn: 215268
2014-08-09 08:57:23 +08:00
Module *Result = new Module(ModuleName, SourceLocation(), Parent,
[modules] Start moving the module visibility information off the Module itself. 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. llvm-svn: 236300
2015-05-01 09:53:09 +08:00
/*IsFramework=*/true, /*IsExplicit=*/false,
NumCreatedModules++);
Refactor the module map file used for uniquing a module name out of class Module. It's almost always going to be the same as getContainingModule() for top-level modules, so just add a map to cover the remaining cases. This lets us do less bookkeeping to keep the ModuleMap fields up to date. llvm-svn: 215268
2014-08-09 08:57:23 +08:00
InferredModuleAllowedBy[Result] = ModuleMapFile;
Result->IsInferred = true;
[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
2016-02-20 06:25:36 +08:00
if (!Parent) {
if (LangOpts.CurrentModule == ModuleName)
SourceModule = Result;
Modules[ModuleName] = Result;
Module use declarations (II) Review: http://llvm-reviews.chandlerc.com/D1546. I have picked up this patch form Lawrence (http://llvm-reviews.chandlerc.com/D1063) and did a few changes. From the original change description (updated as appropriate): This patch adds a check that ensures that modules only use modules they have so declared. To this end, it adds a statement on intended module use to the module.map grammar: use module-id A module can then only use headers from other modules if it 'uses' them. This enforcement is off by default, but may be turned on with the new option -fmodules-decluse. When enforcing the module semantics, we also need to consider a source file part of a module. This is achieved with a compiler option -fmodule-name=<module-id>. The compiler at present only applies restrictions to the module directly being built. llvm-svn: 191283
2013-09-24 17:14:14 +08:00
}
Inherit attributes when infering a framework module If a module map contains framework module * [extern_c] {} We will now infer [extern_c] on the inferred framework modules (we already inferred [system] as a special case). llvm-svn: 225803
2015-01-14 01:47:44 +08:00
Result->IsSystem |= Attrs.IsSystem;
Result->IsExternC |= Attrs.IsExternC;
Result->ConfigMacrosExhaustive |= Attrs.IsExhaustive;
[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
2016-10-21 09:41:56 +08:00
Result->NoUndeclaredIncludes |= Attrs.NoUndeclaredIncludes;
[modules] Retain the name as written for umbrella headers and directories, rather than converting to an absolute path. No observable change expected, but this allows us to correctly compute the module for an umbrella header, which later changes will require. llvm-svn: 237508
2015-05-16 10:28:53 +08:00
Result->Directory = FrameworkDir;
Inherit attributes when infering a framework module If a module map contains framework module * [extern_c] {} We will now infer [extern_c] on the inferred framework modules (we already inferred [system] as a special case). llvm-svn: 225803
2015-01-14 01:47:44 +08:00
Tweak the syntax of umbrella headers, so that "umbrella" is treated as a modifier for a header declarartion, e.g., umbrella header "headername" Collapse the umbrella-handling code in the parser into the header-handling code, so we don't duplicate the header-search logic. llvm-svn: 146159
2011-12-09 02:00:48 +08:00
// umbrella header "umbrella-header-name"
[modules] Retain the name as written for umbrella headers and directories, rather than converting to an absolute path. No observable change expected, but this allows us to correctly compute the module for an umbrella header, which later changes will require. llvm-svn: 237508
2015-05-16 10:28:53 +08:00
//
// The "Headers/" component of the name is implied because this is
// a framework module.
setUmbrellaHeader(Result, UmbrellaHeader, ModuleName + ".h");
Inferred framework modules automatically export anything they import (i.e., 'export *'), to better match the semantics of headers. llvm-svn: 145813
2011-12-06 01:40:25 +08:00
// export *
[C++11] Use 'nullptr'. Lex edition. llvm-svn: 209083
2014-05-18 07:10:59 +08:00
Result->Exports.push_back(Module::ExportDecl(nullptr, true));
Implement inferred submodules support, which (when requested) implicitly generates submodules corresponding to the headers that fall within a module. llvm-svn: 145887
2011-12-06 09:10:29 +08:00
// module * { export * }
Result->InferSubmodules = true;
Result->InferExportWildcard = true;
When inferring a module map for a framework, infer subframework modules for each of its subframeworks. llvm-svn: 145957
2011-12-07 03:39:29 +08:00
// Look for subframeworks.
Replace llvm::error_code with std::error_code. llvm-svn: 210780
2014-06-12 22:02:15 +08:00
std::error_code EC;
Basic: import SmallString<> into clang namespace (I was going to fix the TODO about DenseMap too, but that would break self-host right now. See PR11922.) llvm-svn: 149799
2012-02-05 10:13:05 +08:00
SmallString<128> SubframeworksDirName
Convert paths to native format before constructing a directory_iterator for them. llvm-svn: 146154
2011-12-09 00:13:24 +08:00
= StringRef(FrameworkDir->getName());
When inferring a module map for a framework, infer subframework modules for each of its subframeworks. llvm-svn: 145957
2011-12-07 03:39:29 +08:00
llvm::sys::path::append(SubframeworksDirName, "Frameworks");
Simplify code with the in place path::native. No functionality change. llvm-svn: 190515
2013-09-11 19:23:15 +08:00
llvm::sys::path::native(SubframeworksDirName);
[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
2016-05-17 00:46:01 +08:00
vfs::FileSystem &FS = *FileMgr.getVirtualFileSystem();
for (vfs::directory_iterator Dir = FS.dir_begin(SubframeworksDirName, EC),
DirEnd;
When inferring a module map for a framework, infer subframework modules for each of its subframeworks. llvm-svn: 145957
2011-12-07 03:39:29 +08:00
Dir != DirEnd && !EC; Dir.increment(EC)) {
[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
2016-05-17 00:46:01 +08:00
if (!StringRef(Dir->getName()).endswith(".framework"))
When inferring a module map for a framework, infer subframework modules for each of its subframeworks. llvm-svn: 145957
2011-12-07 03:39:29 +08:00
continue;
Following up on r164620, cope with symlinking from an embedded framework location out to a top-level framework. Such frameworks are not really embedded at all. llvm-svn: 164774
2012-09-27 22:50:15 +08:00
[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
2016-05-17 00:46:01 +08:00
if (const DirectoryEntry *SubframeworkDir =
FileMgr.getDirectory(Dir->getName())) {
Following up on r164620, cope with symlinking from an embedded framework location out to a top-level framework. Such frameworks are not really embedded at all. llvm-svn: 164774
2012-09-27 22:50:15 +08:00
// Note: as an egregious but useful hack, we use the real path here and
// check whether it is actually a subdirectory of the parent directory.
// This will not be the case if the 'subframework' is actually a symlink
// out to a top-level framework.
Since we're stuck with realpath for the header <-> module mapping, factor the realpath calls into FileManager::getCanonicalName() so we can cache the results of this epically slow operation. 5% speedup on my modules test, and realpath drops out of the profile. llvm-svn: 173542
2013-01-26 08:55:12 +08:00
StringRef SubframeworkDirName = FileMgr.getCanonicalName(SubframeworkDir);
bool FoundParent = false;
do {
// Get the parent directory name.
SubframeworkDirName
= llvm::sys::path::parent_path(SubframeworkDirName);
if (SubframeworkDirName.empty())
break;
if (FileMgr.getDirectory(SubframeworkDirName) == FrameworkDir) {
FoundParent = true;
break;
}
} while (true);
Following up on r164620, cope with symlinking from an embedded framework location out to a top-level framework. Such frameworks are not really embedded at all. llvm-svn: 164774
2012-09-27 22:50:15 +08:00
Since we're stuck with realpath for the header <-> module mapping, factor the realpath calls into FileManager::getCanonicalName() so we can cache the results of this epically slow operation. 5% speedup on my modules test, and realpath drops out of the profile. llvm-svn: 173542
2013-01-26 08:55:12 +08:00
if (!FoundParent)
continue;
Following up on r164620, cope with symlinking from an embedded framework location out to a top-level framework. Such frameworks are not really embedded at all. llvm-svn: 164774
2012-09-27 22:50:15 +08:00
When inferring a module map for a framework, infer subframework modules for each of its subframeworks. llvm-svn: 145957
2011-12-07 03:39:29 +08:00
// FIXME: Do we want to warn about subframeworks without umbrella headers?
[Modules] Be consistent about finding a module for framework headers 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 llvm-svn: 241258
2015-07-02 21:19:48 +08:00
inferFrameworkModule(SubframeworkDir, Attrs, Result);
When inferring a module map for a framework, infer subframework modules for each of its subframeworks. llvm-svn: 145957
2011-12-07 03:39:29 +08:00
}
}
Don't infer a submodule for a framework's private header, at least for now. llvm-svn: 148117
2012-01-14 00:54:27 +08:00
Infer "link" lines for top-level frameworks. Essentially, a framework will have a shared library with the same name as its framework (and no suffix!) within its .framework directory. Detect this both when inferring the whole top-level framework and when parsing a module map. llvm-svn: 172439
2013-01-15 01:57:51 +08:00
// If the module is a top-level framework, automatically link against the
// framework.
if (!Result->isSubFramework()) {
inferFrameworkLink(Result, FrameworkDir, FileMgr);
}
When we're loading a framework header, first try to turn the framework into a module. This module can either be loaded from a module map in the framework directory (which isn't quite working yet) or inferred from an umbrella header (which does work, and replaces the existing hack). llvm-svn: 144877
2011-11-17 09:41:17 +08:00
return Result;
}
[modules] Retain the name as written for umbrella headers and directories, rather than converting to an absolute path. No observable change expected, but this allows us to correctly compute the module for an umbrella header, which later changes will require. llvm-svn: 237508
2015-05-16 10:28:53 +08:00
void ModuleMap::setUmbrellaHeader(Module *Mod, const FileEntry *UmbrellaHeader,
Twine NameAsWritten) {
Allow a header to be part of multiple modules. This patch changes two things: a) Allow a header to be part of multiple modules. The reasoning is that in existing codebases that have a module-like build system, the same headers might be used in several build targets. Simple reasons might be that they defined different classes that are declared in the same header. Supporting a header as a part of multiple modules will make the transistion easier for those cases. A later step in clang can then determine whether the two modules are actually compatible and can be merged and error out appropriately. The later check is similar to what needs to be done for template specializations anyway. b) Allow modules to be stored in a directory tree separate from the headers they describe. Review: http://llvm-reviews.chandlerc.com/D1951 llvm-svn: 193151
2013-10-22 16:09:47 +08:00
Headers[UmbrellaHeader].push_back(KnownHeader(Mod, NormalHeader));
Within the module representation, generalize the notion of an umbrella header to also support umbrella directories. The umbrella directory for an umbrella header is the directory in which the umbrella header resides. No functionality change yet, but it's coming. llvm-svn: 146158
2011-12-09 01:39:04 +08:00
Mod->Umbrella = UmbrellaHeader;
[modules] Retain the name as written for umbrella headers and directories, rather than converting to an absolute path. No observable change expected, but this allows us to correctly compute the module for an umbrella header, which later changes will require. llvm-svn: 237508
2015-05-16 10:28:53 +08:00
Mod->UmbrellaAsWritten = NameAsWritten.str();
Implement the notion of umbrella directories, which implicity cover all of the headers below that particular directory. Use umbrella directories as a clean way to deal with (1) directories/frameworks that don't have an umbrella header, but don't want to enumerate all of their headers, and (2) PrivateHeaders, which we never want to enumerate and want to keep separate from the main umbrella header. This also eliminates a little more of the "magic" for private headers, and frameworks in general. llvm-svn: 146235
2011-12-09 10:04:43 +08:00
UmbrellaDirs[UmbrellaHeader->getDir()] = Mod;
[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
2016-05-14 06:21:51 +08:00
// Notify callbacks that we just added a new header.
for (const auto &Cb : Callbacks)
Cb->moduleMapAddUmbrellaHeader(&SourceMgr.getFileManager(), UmbrellaHeader);
Implement inferred submodules support, which (when requested) implicitly generates submodules corresponding to the headers that fall within a module. llvm-svn: 145887
2011-12-06 09:10:29 +08:00
}
[modules] Retain the name as written for umbrella headers and directories, rather than converting to an absolute path. No observable change expected, but this allows us to correctly compute the module for an umbrella header, which later changes will require. llvm-svn: 237508
2015-05-16 10:28:53 +08:00
void ModuleMap::setUmbrellaDir(Module *Mod, const DirectoryEntry *UmbrellaDir,
Twine NameAsWritten) {
Implement umbrella directories for modules, which are similar to umbrella headers in the sense that all of the headers within that directory (and eventually its subdirectories) are considered to be part of the module with that umbrella directory. However, unlike umbrella headers, which are expected to include all of the headers within their subdirectories, Clang will automatically include all of the headers it finds in the named subdirectory. The intent here is to allow a module map to trivially turn a subdirectory into a module, where the module's structure can mimic the directory structure. llvm-svn: 146165
2011-12-09 03:11:24 +08:00
Mod->Umbrella = UmbrellaDir;
[modules] Retain the name as written for umbrella headers and directories, rather than converting to an absolute path. No observable change expected, but this allows us to correctly compute the module for an umbrella header, which later changes will require. llvm-svn: 237508
2015-05-16 10:28:53 +08:00
Mod->UmbrellaAsWritten = NameAsWritten.str();
Implement umbrella directories for modules, which are similar to umbrella headers in the sense that all of the headers within that directory (and eventually its subdirectories) are considered to be part of the module with that umbrella directory. However, unlike umbrella headers, which are expected to include all of the headers within their subdirectories, Clang will automatically include all of the headers it finds in the named subdirectory. The intent here is to allow a module map to trivially turn a subdirectory into a module, where the module's structure can mimic the directory structure. llvm-svn: 146165
2011-12-09 03:11:24 +08:00
UmbrellaDirs[UmbrellaDir] = Mod;
}
[modules] Track how 'header' directives were written in module map files, rather than trying to extract this information from the FileEntry after the fact. This has a number of beneficial effects. For instance, diagnostic messages for failed module builds give a path relative to the "module root" rather than an absolute file path, and the contents of the module includes file is no longer dependent on what files the including TU happened to inspect prior to triggering the module build. llvm-svn: 223095
2014-12-02 08:08:08 +08:00
static Module::HeaderKind headerRoleToKind(ModuleMap::ModuleHeaderRole Role) {
ModuleMap::addHeader(): Appease msc17. llvm-svn: 220639
2014-10-26 21:12:35 +08:00
switch ((int)Role) {
[modules] Track how 'header' directives were written in module map files, rather than trying to extract this information from the FileEntry after the fact. This has a number of beneficial effects. For instance, diagnostic messages for failed module builds give a path relative to the "module root" rather than an absolute file path, and the contents of the module includes file is no longer dependent on what files the including TU happened to inspect prior to triggering the module build. llvm-svn: 223095
2014-12-02 08:08:08 +08:00
default: llvm_unreachable("unknown header role");
case ModuleMap::NormalHeader:
return Module::HK_Normal;
case ModuleMap::PrivateHeader:
return Module::HK_Private;
case ModuleMap::TextualHeader:
return Module::HK_Textual;
case ModuleMap::PrivateHeader | ModuleMap::TextualHeader:
return Module::HK_PrivateTextual;
ModuleMap::addHeader(): Appease msc17. llvm-svn: 220639
2014-10-26 21:12:35 +08:00
}
[modules] Track how 'header' directives were written in module map files, rather than trying to extract this information from the FileEntry after the fact. This has a number of beneficial effects. For instance, diagnostic messages for failed module builds give a path relative to the "module root" rather than an absolute file path, and the contents of the module includes file is no longer dependent on what files the including TU happened to inspect prior to triggering the module build. llvm-svn: 223095
2014-12-02 08:08:08 +08:00
}
[modules] Support combining 'textual' with 'private'. llvm-svn: 220589
2014-10-25 04:23:01 +08:00
[modules] Track how 'header' directives were written in module map files, rather than trying to extract this information from the FileEntry after the fact. This has a number of beneficial effects. For instance, diagnostic messages for failed module builds give a path relative to the "module root" rather than an absolute file path, and the contents of the module includes file is no longer dependent on what files the including TU happened to inspect prior to triggering the module build. llvm-svn: 223095
2014-12-02 08:08:08 +08:00
void ModuleMap::addHeader(Module *Mod, Module::Header Header,
[modules] Remove unnecessary deserialization of fully-external HeaderFileInfos for all files we've seen in this compilation. llvm-svn: 245881
2015-08-25 05:59:32 +08:00
ModuleHeaderRole Role, bool Imported) {
[modules] Fix HeaderFileInfo serialization to store all the known owning modules for a header, not just the current favourite. llvm-svn: 245390
2015-08-19 07:42:23 +08:00
KnownHeader KH(Mod, Role);
// Only add each header to the headers list once.
// FIXME: Should we diagnose if a header is listed twice in the
// same module definition?
auto &HeaderList = Headers[Header.Entry];
for (auto H : HeaderList)
if (H == KH)
return;
Implement inferred submodules support, which (when requested) implicitly generates submodules corresponding to the headers that fall within a module. llvm-svn: 145887
2011-12-06 09:10:29 +08:00
[modules] Fix HeaderFileInfo serialization to store all the known owning modules for a header, not just the current favourite. llvm-svn: 245390
2015-08-19 07:42:23 +08:00
HeaderList.push_back(KH);
Use after move bug fixes Summary: Bunch of fixed bugs in Clang after running misc-use-after-move in clang-tidy. Reviewers: rsmith, mboehme Subscribers: cfe-commits, klimek Differential Revision: https://reviews.llvm.org/D27752 llvm-svn: 290424
2016-12-23 19:40:44 +08:00
Mod->Headers[headerRoleToKind(Role)].push_back(Header);
[modules] Fix HeaderFileInfo serialization to store all the known owning modules for a header, not just the current favourite. llvm-svn: 245390
2015-08-19 07:42:23 +08:00
[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
2016-02-20 06:25:36 +08:00
bool isCompilingModuleHeader =
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
2016-08-26 08:14:38 +08:00
LangOpts.isCompilingModule() && Mod->getTopLevelModule() == SourceModule;
[modules] Remove unnecessary deserialization of fully-external HeaderFileInfos for all files we've seen in this compilation. llvm-svn: 245881
2015-08-25 05:59:32 +08:00
if (!Imported || isCompilingModuleHeader) {
// When we import HeaderFileInfo, the external source is expected to
// set the isModuleHeader flag itself.
HeaderInfo.MarkFileModuleHeader(Header.Entry, Role,
isCompilingModuleHeader);
}
[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
2016-03-31 07:54:25 +08:00
// Notify callbacks that we just added a new header.
for (const auto &Cb : Callbacks)
[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
2016-05-07 07:21:50 +08:00
Cb->moduleMapAddHeader(Header.Entry->getName());
[modules] Track how 'header' directives were written in module map files, rather than trying to extract this information from the FileEntry after the fact. This has a number of beneficial effects. For instance, diagnostic messages for failed module builds give a path relative to the "module root" rather than an absolute file path, and the contents of the module includes file is no longer dependent on what files the including TU happened to inspect prior to triggering the module build. llvm-svn: 223095
2014-12-02 08:08:08 +08:00
}
Refactor implementation of 'exclude header'. This was not a real header role, and was never exposed to clients of ModuleMap. Remove the enumeration value for it and track it as marking the header as 'known' rather than creating an extra KnownHeader entry that *every single* client ignores. llvm-svn: 220460
2014-10-23 10:01:19 +08:00
[modules] Track how 'header' directives were written in module map files, rather than trying to extract this information from the FileEntry after the fact. This has a number of beneficial effects. For instance, diagnostic messages for failed module builds give a path relative to the "module root" rather than an absolute file path, and the contents of the module includes file is no longer dependent on what files the including TU happened to inspect prior to triggering the module build. llvm-svn: 223095
2014-12-02 08:08:08 +08:00
void ModuleMap::excludeHeader(Module *Mod, Module::Header Header) {
Refactor implementation of 'exclude header'. This was not a real header role, and was never exposed to clients of ModuleMap. Remove the enumeration value for it and track it as marking the header as 'known' rather than creating an extra KnownHeader entry that *every single* client ignores. llvm-svn: 220460
2014-10-23 10:01:19 +08:00
// Add this as a known header so we won't implicitly add it to any
// umbrella directory module.
// FIXME: Should we only exclude it from umbrella modules within the
// specified module?
[modules] Track how 'header' directives were written in module map files, rather than trying to extract this information from the FileEntry after the fact. This has a number of beneficial effects. For instance, diagnostic messages for failed module builds give a path relative to the "module root" rather than an absolute file path, and the contents of the module includes file is no longer dependent on what files the including TU happened to inspect prior to triggering the module build. llvm-svn: 223095
2014-12-02 08:08:08 +08:00
(void) Headers[Header.Entry];
Mod->Headers[Module::HK_Excluded].push_back(std::move(Header));
Refactor implementation of 'exclude header'. This was not a real header role, and was never exposed to clients of ModuleMap. Remove the enumeration value for it and track it as marking the header as 'known' rather than creating an extra KnownHeader entry that *every single* client ignores. llvm-svn: 220460
2014-10-23 10:01:19 +08:00
}
Teach the module import mechanism how to rebuild modules expressed via module map, rather than assuming that there is an umbrella header. This allows us to automatically build umbrella-less modules. llvm-svn: 145415
2011-11-30 03:06:37 +08:00
const FileEntry *
Verify all the module map files for a pcm are the same on load We already verified the primary module map file (either the one that defines the top-level module, or the one that allows inferring it if it is an inferred framework module). Now we also verify any other module map files that define submodules, such as when there is a module.private.modulemap file. llvm-svn: 215455
2014-08-13 00:42:33 +08:00
ModuleMap::getContainingModuleMapFile(const Module *Module) const {
Use the same SourceManager for ModuleMaps and compilations. This allows using virtual file mappings on the original SourceManager to map in virtual module.map files. Without this patch, the ModuleMap search will find a module.map file (as the FileEntry exists in the FileManager), but will be unable to get the content from the SourceManager (as ModuleMap previously created its own SourceManager). Two problems needed to be fixed which this patch exposed: 1. Storing the inferred module map When writing out a module, the ASTWriter stores the names of the files in the main source manager; when loading the AST again, the ASTReader errs out if such a file is found missing, unless it is overridden. Previously CompilerInstance's compileModule method would store the inferred module map to a temporary file; the problem with this approach is that now that the module map is handled by the main source manager, the ASTWriter stores the name of the temporary module map as source to the compilation; later, when the module is loaded, the temporary file has already been deleted, which leads to a compilation error. This patch changes the inferred module map to instead inject a virtual file into the source manager. This both saves some disk IO, and works with how the ASTWriter/ASTReader handle overridden source files. 2. Changing test input in test/Modules/Inputs/* Now that the module map file is handled by the main source manager, the VerifyDiagnosticConsumer will not ignore diagnostics created while parsing the module map file. The module test test/Modules/renamed.m uses -I test/Modules/Inputs and triggers recursive loading of all module maps in test/Modules/Inputs, some of which had conflicting names, thus leading errors while parsing the module maps. Those diagnostics already occur on trunk, but before this patch they would not break the test, as they were ignored by the VerifyDiagnosticConsumer. This patch thus changes the module maps that have been recently introduced which broke the invariant of compatible modules maps in test/Modules/Inputs. llvm-svn: 193314
2013-10-24 15:51:24 +08:00
if (Module->DefinitionLoc.isInvalid())
[C++11] Use 'nullptr'. Lex edition. llvm-svn: 209083
2014-05-18 07:10:59 +08:00
return nullptr;
Teach the module import mechanism how to rebuild modules expressed via module map, rather than assuming that there is an umbrella header. This allows us to automatically build umbrella-less modules. llvm-svn: 145415
2011-11-30 03:06:37 +08:00
Use the same SourceManager for ModuleMaps and compilations. This allows using virtual file mappings on the original SourceManager to map in virtual module.map files. Without this patch, the ModuleMap search will find a module.map file (as the FileEntry exists in the FileManager), but will be unable to get the content from the SourceManager (as ModuleMap previously created its own SourceManager). Two problems needed to be fixed which this patch exposed: 1. Storing the inferred module map When writing out a module, the ASTWriter stores the names of the files in the main source manager; when loading the AST again, the ASTReader errs out if such a file is found missing, unless it is overridden. Previously CompilerInstance's compileModule method would store the inferred module map to a temporary file; the problem with this approach is that now that the module map is handled by the main source manager, the ASTWriter stores the name of the temporary module map as source to the compilation; later, when the module is loaded, the temporary file has already been deleted, which leads to a compilation error. This patch changes the inferred module map to instead inject a virtual file into the source manager. This both saves some disk IO, and works with how the ASTWriter/ASTReader handle overridden source files. 2. Changing test input in test/Modules/Inputs/* Now that the module map file is handled by the main source manager, the VerifyDiagnosticConsumer will not ignore diagnostics created while parsing the module map file. The module test test/Modules/renamed.m uses -I test/Modules/Inputs and triggers recursive loading of all module maps in test/Modules/Inputs, some of which had conflicting names, thus leading errors while parsing the module maps. Those diagnostics already occur on trunk, but before this patch they would not break the test, as they were ignored by the VerifyDiagnosticConsumer. This patch thus changes the module maps that have been recently introduced which broke the invariant of compatible modules maps in test/Modules/Inputs. llvm-svn: 193314
2013-10-24 15:51:24 +08:00
return SourceMgr.getFileEntryForID(
SourceMgr.getFileID(Module->DefinitionLoc));
Teach the module import mechanism how to rebuild modules expressed via module map, rather than assuming that there is an umbrella header. This allows us to automatically build umbrella-less modules. llvm-svn: 145415
2011-11-30 03:06:37 +08:00
}
Verify all the module map files for a pcm are the same on load We already verified the primary module map file (either the one that defines the top-level module, or the one that allows inferring it if it is an inferred framework module). Now we also verify any other module map files that define submodules, such as when there is a module.private.modulemap file. llvm-svn: 215455
2014-08-13 00:42:33 +08:00
const FileEntry *ModuleMap::getModuleMapFileForUniquing(const Module *M) const {
Refactor the module map file used for uniquing a module name out of class Module. It's almost always going to be the same as getContainingModule() for top-level modules, so just add a map to cover the remaining cases. This lets us do less bookkeeping to keep the ModuleMap fields up to date. llvm-svn: 215268
2014-08-09 08:57:23 +08:00
if (M->IsInferred) {
assert(InferredModuleAllowedBy.count(M) && "missing inferred module map");
return InferredModuleAllowedBy.find(M)->second;
}
return getContainingModuleMapFile(M);
}
void ModuleMap::setInferredModuleAllowedBy(Module *M, const FileEntry *ModMap) {
assert(M->IsInferred && "module not inferred");
InferredModuleAllowedBy[M] = ModMap;
}
Annotate dump() methods with LLVM_DUMP_METHOD, addressing Richard Smith r259192 post commit comment. llvm-svn: 259232
2016-01-30 03:38:18 +08:00
LLVM_DUMP_METHOD void ModuleMap::dump() {
Introduce basic support for parsing module map files. Module map files provide a way to map between headers and modules, so that we can layer a module system on top of existing headers without changing those headers at all. This commit introduces the module map file parser and the module map that it generates, and wires up the module map file parser so that we'll automatically find module map files as part of header search. Note that we don't yet use the information stored in the module map. llvm-svn: 144402
2011-11-12 03:10:28 +08:00
llvm::errs() << "Modules:";
for (llvm::StringMap<Module *>::iterator M = Modules.begin(),
MEnd = Modules.end();
M != MEnd; ++M)
Expose the printing of module maps as part of the ModuleMap::Module interface. No functionality change. llvm-svn: 145411
2011-11-30 02:17:59 +08:00
M->getValue()->print(llvm::errs(), 2);
Introduce basic support for parsing module map files. Module map files provide a way to map between headers and modules, so that we can layer a module system on top of existing headers without changing those headers at all. This commit introduces the module map file parser and the module map that it generates, and wires up the module map file parser so that we'll automatically find module map files as part of header search. Note that we don't yet use the information stored in the module map. llvm-svn: 144402
2011-11-12 03:10:28 +08:00
llvm::errs() << "Headers:";
Introduce the notion of excluded headers into the module map description. Previously, one could emulate this behavior by placing the header in an always-unavailable submodule, but Argyrios guilted me into expressing this idea properly. llvm-svn: 165921
2012-10-15 14:28:11 +08:00
for (HeadersMap::iterator H = Headers.begin(), HEnd = Headers.end();
Introduce basic support for parsing module map files. Module map files provide a way to map between headers and modules, so that we can layer a module system on top of existing headers without changing those headers at all. This commit introduces the module map file parser and the module map that it generates, and wires up the module map file parser so that we'll automatically find module map files as part of header search. Note that we don't yet use the information stored in the module map. llvm-svn: 144402
2011-11-12 03:10:28 +08:00
H != HEnd; ++H) {
Allow a header to be part of multiple modules. This patch changes two things: a) Allow a header to be part of multiple modules. The reasoning is that in existing codebases that have a module-like build system, the same headers might be used in several build targets. Simple reasons might be that they defined different classes that are declared in the same header. Supporting a header as a part of multiple modules will make the transistion easier for those cases. A later step in clang can then determine whether the two modules are actually compatible and can be merged and error out appropriately. The later check is similar to what needs to be done for template specializations anyway. b) Allow modules to be stored in a directory tree separate from the headers they describe. Review: http://llvm-reviews.chandlerc.com/D1951 llvm-svn: 193151
2013-10-22 16:09:47 +08:00
llvm::errs() << " \"" << H->first->getName() << "\" -> ";
for (SmallVectorImpl<KnownHeader>::const_iterator I = H->second.begin(),
E = H->second.end();
I != E; ++I) {
if (I != H->second.begin())
llvm::errs() << ",";
llvm::errs() << I->getModule()->getFullModuleName();
}
llvm::errs() << "\n";
Introduce basic support for parsing module map files. Module map files provide a way to map between headers and modules, so that we can layer a module system on top of existing headers without changing those headers at all. This commit introduces the module map file parser and the module map that it generates, and wires up the module map file parser so that we'll automatically find module map files as part of header search. Note that we don't yet use the information stored in the module map. llvm-svn: 144402
2011-11-12 03:10:28 +08:00
}
}
Implementing parsing and resolution of module export declarations within module maps, which will (eventually) be used to re-export a module from another module. There are still some pieces missing, however. llvm-svn: 145665
2011-12-02 09:47:07 +08:00
bool ModuleMap::resolveExports(Module *Mod, bool Complain) {
[modules] Add local submodule visibility support for declarations. 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. llvm-svn: 237473
2015-05-16 04:05:43 +08:00
auto Unresolved = std::move(Mod->UnresolvedExports);
Mod->UnresolvedExports.clear();
for (auto &UE : Unresolved) {
Module::ExportDecl Export = resolveExport(Mod, UE, Complain);
Implement support for wildcard exports in modules, allowing a module to re-export anything that it imports. This opt-in feature makes a module behave more like a header, because it can be used to re-export the transitive closure of a (sub)module's dependencies. llvm-svn: 145811
2011-12-06 01:28:06 +08:00
if (Export.getPointer() || Export.getInt())
Implementing parsing and resolution of module export declarations within module maps, which will (eventually) be used to re-export a module from another module. There are still some pieces missing, however. llvm-svn: 145665
2011-12-02 09:47:07 +08:00
Mod->Exports.push_back(Export);
else
[modules] Add local submodule visibility support for declarations. 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. llvm-svn: 237473
2015-05-16 04:05:43 +08:00
Mod->UnresolvedExports.push_back(UE);
Implementing parsing and resolution of module export declarations within module maps, which will (eventually) be used to re-export a module from another module. There are still some pieces missing, however. llvm-svn: 145665
2011-12-02 09:47:07 +08:00
}
[modules] Add local submodule visibility support for declarations. 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. llvm-svn: 237473
2015-05-16 04:05:43 +08:00
return !Mod->UnresolvedExports.empty();
Implementing parsing and resolution of module export declarations within module maps, which will (eventually) be used to re-export a module from another module. There are still some pieces missing, however. llvm-svn: 145665
2011-12-02 09:47:07 +08:00
}
Module use declarations (II) Review: http://llvm-reviews.chandlerc.com/D1546. I have picked up this patch form Lawrence (http://llvm-reviews.chandlerc.com/D1063) and did a few changes. From the original change description (updated as appropriate): This patch adds a check that ensures that modules only use modules they have so declared. To this end, it adds a statement on intended module use to the module.map grammar: use module-id A module can then only use headers from other modules if it 'uses' them. This enforcement is off by default, but may be turned on with the new option -fmodules-decluse. When enforcing the module semantics, we also need to consider a source file part of a module. This is achieved with a compiler option -fmodule-name=<module-id>. The compiler at present only applies restrictions to the module directly being built. llvm-svn: 191283
2013-09-24 17:14:14 +08:00
bool ModuleMap::resolveUses(Module *Mod, bool Complain) {
[modules] Add local submodule visibility support for declarations. 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. llvm-svn: 237473
2015-05-16 04:05:43 +08:00
auto Unresolved = std::move(Mod->UnresolvedDirectUses);
Mod->UnresolvedDirectUses.clear();
for (auto &UDU : Unresolved) {
Module *DirectUse = resolveModuleId(UDU, Mod, Complain);
Module use declarations (II) Review: http://llvm-reviews.chandlerc.com/D1546. I have picked up this patch form Lawrence (http://llvm-reviews.chandlerc.com/D1063) and did a few changes. From the original change description (updated as appropriate): This patch adds a check that ensures that modules only use modules they have so declared. To this end, it adds a statement on intended module use to the module.map grammar: use module-id A module can then only use headers from other modules if it 'uses' them. This enforcement is off by default, but may be turned on with the new option -fmodules-decluse. When enforcing the module semantics, we also need to consider a source file part of a module. This is achieved with a compiler option -fmodule-name=<module-id>. The compiler at present only applies restrictions to the module directly being built. llvm-svn: 191283
2013-09-24 17:14:14 +08:00
if (DirectUse)
Mod->DirectUses.push_back(DirectUse);
else
[modules] Add local submodule visibility support for declarations. 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. llvm-svn: 237473
2015-05-16 04:05:43 +08:00
Mod->UnresolvedDirectUses.push_back(UDU);
Module use declarations (II) Review: http://llvm-reviews.chandlerc.com/D1546. I have picked up this patch form Lawrence (http://llvm-reviews.chandlerc.com/D1063) and did a few changes. From the original change description (updated as appropriate): This patch adds a check that ensures that modules only use modules they have so declared. To this end, it adds a statement on intended module use to the module.map grammar: use module-id A module can then only use headers from other modules if it 'uses' them. This enforcement is off by default, but may be turned on with the new option -fmodules-decluse. When enforcing the module semantics, we also need to consider a source file part of a module. This is achieved with a compiler option -fmodule-name=<module-id>. The compiler at present only applies restrictions to the module directly being built. llvm-svn: 191283
2013-09-24 17:14:14 +08:00
}
[modules] Add local submodule visibility support for declarations. 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. llvm-svn: 237473
2015-05-16 04:05:43 +08:00
return !Mod->UnresolvedDirectUses.empty();
Module use declarations (II) Review: http://llvm-reviews.chandlerc.com/D1546. I have picked up this patch form Lawrence (http://llvm-reviews.chandlerc.com/D1063) and did a few changes. From the original change description (updated as appropriate): This patch adds a check that ensures that modules only use modules they have so declared. To this end, it adds a statement on intended module use to the module.map grammar: use module-id A module can then only use headers from other modules if it 'uses' them. This enforcement is off by default, but may be turned on with the new option -fmodules-decluse. When enforcing the module semantics, we also need to consider a source file part of a module. This is achieved with a compiler option -fmodule-name=<module-id>. The compiler at present only applies restrictions to the module directly being built. llvm-svn: 191283
2013-09-24 17:14:14 +08:00
}
<rdar://problem/12368093> Extend module maps with a 'conflict' declaration, and warn when a newly-imported module conflicts with an already-imported module. llvm-svn: 177577
2013-03-21 05:10:35 +08:00
bool ModuleMap::resolveConflicts(Module *Mod, bool Complain) {
[modules] Add local submodule visibility support for declarations. 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. llvm-svn: 237473
2015-05-16 04:05:43 +08:00
auto Unresolved = std::move(Mod->UnresolvedConflicts);
<rdar://problem/12368093> Extend module maps with a 'conflict' declaration, and warn when a newly-imported module conflicts with an already-imported module. llvm-svn: 177577
2013-03-21 05:10:35 +08:00
Mod->UnresolvedConflicts.clear();
[modules] Add local submodule visibility support for declarations. 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. llvm-svn: 237473
2015-05-16 04:05:43 +08:00
for (auto &UC : Unresolved) {
if (Module *OtherMod = resolveModuleId(UC.Id, Mod, Complain)) {
Module::Conflict Conflict;
Conflict.Other = OtherMod;
Conflict.Message = UC.Message;
Mod->Conflicts.push_back(Conflict);
} else
Mod->UnresolvedConflicts.push_back(UC);
}
return !Mod->UnresolvedConflicts.empty();
<rdar://problem/12368093> Extend module maps with a 'conflict' declaration, and warn when a newly-imported module conflicts with an already-imported module. llvm-svn: 177577
2013-03-21 05:10:35 +08:00
}
When writing a module file, keep track of the set of (sub)modules that it imports, establishing dependencies at the (sub)module granularity. This is not a user-visible change (yet). llvm-svn: 145808
2011-12-06 00:33:54 +08:00
Module *ModuleMap::inferModuleFromLocation(FullSourceLoc Loc) {
if (Loc.isInvalid())
[C++11] Use 'nullptr'. Lex edition. llvm-svn: 209083
2014-05-18 07:10:59 +08:00
return nullptr;
[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
2016-05-17 04:30:03 +08:00
if (UmbrellaDirs.empty() && Headers.empty())
return nullptr;
When writing a module file, keep track of the set of (sub)modules that it imports, establishing dependencies at the (sub)module granularity. This is not a user-visible change (yet). llvm-svn: 145808
2011-12-06 00:33:54 +08:00
// Use the expansion location to determine which module we're in.
FullSourceLoc ExpansionLoc = Loc.getExpansionLoc();
if (!ExpansionLoc.isFileID())
[C++11] Use 'nullptr'. Lex edition. llvm-svn: 209083
2014-05-18 07:10:59 +08:00
return nullptr;
When writing a module file, keep track of the set of (sub)modules that it imports, establishing dependencies at the (sub)module granularity. This is not a user-visible change (yet). llvm-svn: 145808
2011-12-06 00:33:54 +08:00
const SourceManager &SrcMgr = Loc.getManager();
FileID ExpansionFileID = ExpansionLoc.getFileID();
When inferring a submodule ID during module creation, look up the include stack to find the first file that is known to be part of the module. This copes with situations where the module map doesn't completely specify all of the headers that are involved in the module, which can come up when there are very strange #include_next chains (e.g., with weird compiler/stdlib headers like stdarg.h or float.h). llvm-svn: 147662
2012-01-07 01:19:32 +08:00
while (const FileEntry *ExpansionFile
= SrcMgr.getFileEntryForID(ExpansionFileID)) {
// Find the module that owns this header (if any).
This patch adds new private headers to the module map. Private headers may be included from within the module, but not from outside the module. llvm-svn: 184471
2013-06-21 05:14:14 +08:00
if (Module *Mod = findModuleForHeader(ExpansionFile).getModule())
When inferring a submodule ID during module creation, look up the include stack to find the first file that is known to be part of the module. This copes with situations where the module map doesn't completely specify all of the headers that are involved in the module, which can come up when there are very strange #include_next chains (e.g., with weird compiler/stdlib headers like stdarg.h or float.h). llvm-svn: 147662
2012-01-07 01:19:32 +08:00
return Mod;
// No module owns this header, so look up the inclusion chain to see if
// any included header has an associated module.
SourceLocation IncludeLoc = SrcMgr.getIncludeLoc(ExpansionFileID);
if (IncludeLoc.isInvalid())
[C++11] Use 'nullptr'. Lex edition. llvm-svn: 209083
2014-05-18 07:10:59 +08:00
return nullptr;
When inferring a submodule ID during module creation, look up the include stack to find the first file that is known to be part of the module. This copes with situations where the module map doesn't completely specify all of the headers that are involved in the module, which can come up when there are very strange #include_next chains (e.g., with weird compiler/stdlib headers like stdarg.h or float.h). llvm-svn: 147662
2012-01-07 01:19:32 +08:00
ExpansionFileID = SrcMgr.getFileID(IncludeLoc);
}
[C++11] Use 'nullptr'. Lex edition. llvm-svn: 209083
2014-05-18 07:10:59 +08:00
return nullptr;
When writing a module file, keep track of the set of (sub)modules that it imports, establishing dependencies at the (sub)module granularity. This is not a user-visible change (yet). llvm-svn: 145808
2011-12-06 00:33:54 +08:00
}
Introduce basic support for parsing module map files. Module map files provide a way to map between headers and modules, so that we can layer a module system on top of existing headers without changing those headers at all. This commit introduces the module map file parser and the module map that it generates, and wires up the module map file parser so that we'll automatically find module map files as part of header search. Note that we don't yet use the information stored in the module map. llvm-svn: 144402
2011-11-12 03:10:28 +08:00
//----------------------------------------------------------------------------//
// Module map file parser
//----------------------------------------------------------------------------//
namespace clang {
/// \brief A token in a module map file.
struct MMToken {
enum TokenKind {
Implement support for module requirements, which indicate the language features needed for a particular module to be available. This allows mixed-language modules, where certain headers only work under some language variants (e.g., in C++, std.tuple might only be available in C++11 mode). llvm-svn: 147387
2011-12-31 12:05:44 +08:00
Comma,
<rdar://problem/10796651> Introduce configuration macros into module maps. Configuration macros are macros that are intended to alter how a module works, such that we need to build different module variants for different values of these macros. A module can declare its configuration macros, in which case we will complain if the definition of a configation macro on the command line (or lack thereof) differs from the current preprocessor state at the point where the module is imported. This should eliminate some surprises when enabling modules, because "#define CONFIG_MACRO ..." followed by "#include <module/header.h>" would silently ignore the CONFIG_MACRO setting. At least it will no longer be silent about it. Configuration macros are eventually intended to help reduce the number of module variants that need to be built. When the list of configuration macros for a module is exhaustive, we only need to consider the settings for those macros when building/finding the module, which can help isolate modules for various project-specific -D flags that should never affect how modules are build (but currently do). llvm-svn: 177466
2013-03-20 08:22:05 +08:00
ConfigMacros,
<rdar://problem/12368093> Extend module maps with a 'conflict' declaration, and warn when a newly-imported module conflicts with an already-imported module. llvm-svn: 177577
2013-03-21 05:10:35 +08:00
Conflict,
Introduce basic support for parsing module map files. Module map files provide a way to map between headers and modules, so that we can layer a module system on top of existing headers without changing those headers at all. This commit introduces the module map file parser and the module map that it generates, and wires up the module map file parser so that we'll automatically find module map files as part of header search. Note that we don't yet use the information stored in the module map. llvm-svn: 144402
2011-11-12 03:10:28 +08:00
EndOfFile,
HeaderKeyword,
Identifier,
Allow a new syntax in a module requires-declaration: requires ! feature The purpose of this is to allow (for instance) the module map for /usr/include to exclude <tgmath.h> and <complex.h> when building in C++ (these headers are instead provided by the C++ standard library in this case, and the glibc C <tgmath.h> header would otherwise try to include <complex.h>, resulting in a module cycle). llvm-svn: 193549
2013-10-29 06:18:19 +08:00
Exclaim,
Introduce the notion of excluded headers into the module map description. Previously, one could emulate this behavior by placing the header in an always-unavailable submodule, but Argyrios guilted me into expressing this idea properly. llvm-svn: 165921
2012-10-15 14:28:11 +08:00
ExcludeKeyword,
Introduce basic support for parsing module map files. Module map files provide a way to map between headers and modules, so that we can layer a module system on top of existing headers without changing those headers at all. This commit introduces the module map file parser and the module map that it generates, and wires up the module map file parser so that we'll automatically find module map files as part of header search. Note that we don't yet use the information stored in the module map. llvm-svn: 144402
2011-11-12 03:10:28 +08:00
ExplicitKeyword,
Implementing parsing and resolution of module export declarations within module maps, which will (eventually) be used to re-export a module from another module. There are still some pieces missing, however. llvm-svn: 145665
2011-12-02 09:47:07 +08:00
ExportKeyword,
Support for modular module-map-files This patch is the first step to make module-map-files modular (instead of requiring a single "module.map"-file per include directory). This step adds a new "extern module" declaration that enables module-map-files to reference one another along with a very basic implementation. The next steps are: * Combine this with the use-declaration (from http://llvm-reviews.chandlerc.com/D1546) in order to only load module map files required for a specific compilation. * Add an additional flag to start with a specific module-map-file (instead of requiring there to be at least one "module.map"). Review: http://llvm-reviews.chandlerc.com/D1637 llvm-svn: 190497
2013-09-11 15:20:44 +08:00
ExternKeyword,
Add the notion of "framework" modules to module maps. Framework modules (obviously) describe frameworks, and understand the header layout of frameworks. llvm-svn: 144921
2011-11-18 06:09:43 +08:00
FrameworkKeyword,
Implement parsing, AST, (de-)serialization, and placeholder global metadata for linking against the libraries/frameworks for imported modules. The module map language is extended with a new "link" directive that specifies what library or framework to link against when a module is imported, e.g., link "clangAST" or link framework "MyFramework" Importing the corresponding module (or any of its submodules) will eventually link against the named library/framework. For now, I've added some placeholder global metadata that encodes the imported libraries/frameworks, so that we can test that this information gets through to the IR. The format of the data is still under discussion. llvm-svn: 172437
2013-01-15 01:21:00 +08:00
LinkKeyword,
Introduce basic support for parsing module map files. Module map files provide a way to map between headers and modules, so that we can layer a module system on top of existing headers without changing those headers at all. This commit introduces the module map file parser and the module map that it generates, and wires up the module map file parser so that we'll automatically find module map files as part of header search. Note that we don't yet use the information stored in the module map. llvm-svn: 144402
2011-11-12 03:10:28 +08:00
ModuleKeyword,
Implementing parsing and resolution of module export declarations within module maps, which will (eventually) be used to re-export a module from another module. There are still some pieces missing, however. llvm-svn: 145665
2011-12-02 09:47:07 +08:00
Period,
This patch adds new private headers to the module map. Private headers may be included from within the module, but not from outside the module. llvm-svn: 184471
2013-06-21 05:14:14 +08:00
PrivateKeyword,
Introduce basic support for parsing module map files. Module map files provide a way to map between headers and modules, so that we can layer a module system on top of existing headers without changing those headers at all. This commit introduces the module map file parser and the module map that it generates, and wires up the module map file parser so that we'll automatically find module map files as part of header search. Note that we don't yet use the information stored in the module map. llvm-svn: 144402
2011-11-12 03:10:28 +08:00
UmbrellaKeyword,
Module use declarations (II) Review: http://llvm-reviews.chandlerc.com/D1546. I have picked up this patch form Lawrence (http://llvm-reviews.chandlerc.com/D1063) and did a few changes. From the original change description (updated as appropriate): This patch adds a check that ensures that modules only use modules they have so declared. To this end, it adds a statement on intended module use to the module.map grammar: use module-id A module can then only use headers from other modules if it 'uses' them. This enforcement is off by default, but may be turned on with the new option -fmodules-decluse. When enforcing the module semantics, we also need to consider a source file part of a module. This is achieved with a compiler option -fmodule-name=<module-id>. The compiler at present only applies restrictions to the module directly being built. llvm-svn: 191283
2013-09-24 17:14:14 +08:00
UseKeyword,
Implement support for module requirements, which indicate the language features needed for a particular module to be available. This allows mixed-language modules, where certain headers only work under some language variants (e.g., in C++, std.tuple might only be available in C++11 mode). llvm-svn: 147387
2011-12-31 12:05:44 +08:00
RequiresKeyword,
Implementing parsing and resolution of module export declarations within module maps, which will (eventually) be used to re-export a module from another module. There are still some pieces missing, however. llvm-svn: 145665
2011-12-02 09:47:07 +08:00
Star,
Introduce basic support for parsing module map files. Module map files provide a way to map between headers and modules, so that we can layer a module system on top of existing headers without changing those headers at all. This commit introduces the module map file parser and the module map that it generates, and wires up the module map file parser so that we'll automatically find module map files as part of header search. Note that we don't yet use the information stored in the module map. llvm-svn: 144402
2011-11-12 03:10:28 +08:00
StringLiteral,
[modules] Add support for 'textual header' directives. This allows a module to specify that it logically contains a file, but that said file is non-modular and intended for textual inclusion. This allows layering checks to work properly in the presence of such files. llvm-svn: 220448
2014-10-23 07:50:56 +08:00
TextualKeyword,
Introduce basic support for parsing module map files. Module map files provide a way to map between headers and modules, so that we can layer a module system on top of existing headers without changing those headers at all. This commit introduces the module map file parser and the module map that it generates, and wires up the module map file parser so that we'll automatically find module map files as part of header search. Note that we don't yet use the information stored in the module map. llvm-svn: 144402
2011-11-12 03:10:28 +08:00
LBrace,
Introduce module attributes into the module map grammar, along with a single attribute ("system") that allows us to mark a module as being a "system" module. Each of the headers that makes up a system module is considered to be a system header, so that we (for example) suppress warnings there. If a module is being inferred for a framework, and that framework directory is within a system frameworks directory, infer it as a system framework. llvm-svn: 149143
2012-01-28 03:52:33 +08:00
RBrace,
LSquare,
RSquare
Introduce basic support for parsing module map files. Module map files provide a way to map between headers and modules, so that we can layer a module system on top of existing headers without changing those headers at all. This commit introduces the module map file parser and the module map that it generates, and wires up the module map file parser so that we'll automatically find module map files as part of header search. Note that we don't yet use the information stored in the module map. llvm-svn: 144402
2011-11-12 03:10:28 +08:00
} Kind;
unsigned Location;
unsigned StringLength;
const char *StringData;
void clear() {
Kind = EndOfFile;
Location = 0;
StringLength = 0;
[C++11] Use 'nullptr'. Lex edition. llvm-svn: 209083
2014-05-18 07:10:59 +08:00
StringData = nullptr;
Introduce basic support for parsing module map files. Module map files provide a way to map between headers and modules, so that we can layer a module system on top of existing headers without changing those headers at all. This commit introduces the module map file parser and the module map that it generates, and wires up the module map file parser so that we'll automatically find module map files as part of header search. Note that we don't yet use the information stored in the module map. llvm-svn: 144402
2011-11-12 03:10:28 +08:00
}
bool is(TokenKind K) const { return Kind == K; }
SourceLocation getLocation() const {
return SourceLocation::getFromRawEncoding(Location);
}
StringRef getString() const {
return StringRef(StringData, StringLength);
}
};
Introduce inferred framework modules into the module map file, allowing a module map to be placed one level above the '.framework' directories to specify that all .frameworks within that directory can be inferred as framework modules. One can also specifically exclude frameworks known not to work. This makes explicit (and more restricted) behavior modules have had "forever", where *any* .framework was assumed to be able to be built as a module. That's not necessarily true, so we white-list directories (with exclusions) when those directories have been audited. llvm-svn: 167482
2012-11-07 03:39:40 +08:00
Introduce basic support for parsing module map files. Module map files provide a way to map between headers and modules, so that we can layer a module system on top of existing headers without changing those headers at all. This commit introduces the module map file parser and the module map that it generates, and wires up the module map file parser so that we'll automatically find module map files as part of header search. Note that we don't yet use the information stored in the module map. llvm-svn: 144402
2011-11-12 03:10:28 +08:00
class ModuleMapParser {
Lexer &L;
SourceManager &SourceMgr;
Teach TargetInfo to hold on to the TargetOptions with which it was created. llvm-svn: 165943
2012-10-16 00:45:32 +08:00
/// \brief Default target information, used only for string literal
/// parsing.
const TargetInfo *Target;
Introduce basic support for parsing module map files. Module map files provide a way to map between headers and modules, so that we can layer a module system on top of existing headers without changing those headers at all. This commit introduces the module map file parser and the module map that it generates, and wires up the module map file parser so that we'll automatically find module map files as part of header search. Note that we don't yet use the information stored in the module map. llvm-svn: 144402
2011-11-12 03:10:28 +08:00
DiagnosticsEngine &Diags;
ModuleMap &Map;
Allow multiple modules with the same name to coexist in the module cache To differentiate between two modules with the same name, we will consider the path the module map file that they are defined by* part of the ‘key’ for looking up the precompiled module (pcm file). Specifically, this patch renames the precompiled module (pcm) files from cache-path/<module hash>/Foo.pcm to cache-path/<module hash>/Foo-<hash of module map path>.pcm In addition, I’ve taught the ASTReader to re-resolve the names of imported modules during module loading so that if the header search context changes between when a module was originally built and when it is loaded we can rebuild it if necessary. For example, if module A imports module B first time: clang -I /path/to/A -I /path/to/B ... second time: clang -I /path/to/A -I /different/path/to/B ... will now rebuild A as expected. * in the case of inferred modules, we use the module map file that allowed the inference, not the __inferred_module.map file, since the inferred file path is the same for every inferred module. llvm-svn: 206201
2014-04-15 02:00:01 +08:00
/// \brief The current module map file.
const FileEntry *ModuleMapFile;
Introduce basic support for parsing module map files. Module map files provide a way to map between headers and modules, so that we can layer a module system on top of existing headers without changing those headers at all. This commit introduces the module map file parser and the module map that it generates, and wires up the module map file parser so that we'll automatically find module map files as part of header search. Note that we don't yet use the information stored in the module map. llvm-svn: 144402
2011-11-12 03:10:28 +08:00
Reinstate r223753, reverted in r223759 due to breakage of clang-tools-extra. Original commit message: [modules] Add experimental -fmodule-map-file-home-is-cwd flag to -cc1. For files named by -fmodule-map-file=, and files found by 'extern module' directives, this flag specifies that we should resolve filenames relative to the current working directory rather than relative to the directory in which the module map file resides. This is aimed at fixing path handling, in particular for relative -I paths, when building modules that represent components of the current project (rather than libraries installed on the current system, which the current project has as dependencies, where we'd typically expect the module map files to be looked up implicitly). llvm-svn: 223913
2014-12-10 11:09:48 +08:00
/// \brief The directory that file names in this module map file should
/// be resolved relative to.
Resolve the header files named in module map "header" and "umbrella" declarations to actual files. llvm-svn: 144408
2011-11-12 05:55:48 +08:00
const DirectoryEntry *Directory;
Back out my heinous hack that tricked the module generation mechanism into using non-absolute system includes (<foo>)... ... and introduce another hack that is simultaneously more heineous and more effective. We whitelist Clang-supplied headers that augment or override system headers (such as float.h, stdarg.h, and tgmath.h). For these headers, Clang does not provide a module mapping. Instead, a system-supplied module map can refer to these headers in a system module, and Clang will look both in its own include directory and wherever the system-supplied module map suggests, then adds either or both headers. The end result is that Clang-supplied headers get merged into the system-supplied module for the C standard library. As a drive-by, fix up a few dependencies in the _Builtin_instrinsics module. llvm-svn: 149611
2012-02-03 02:42:48 +08:00
/// \brief The directory containing Clang-supplied headers.
const DirectoryEntry *BuiltinIncludeDir;
[Modules] If a module map resides in a system header directory, treat it as a system module. This prevents -pedantic from causing warnings in the system headers used to create modules. Fixes <rdar://problem/14201171>. llvm-svn: 184560
2013-06-22 00:28:10 +08:00
/// \brief Whether this module map is in a system header directory.
bool IsSystem;
Introduce basic support for parsing module map files. Module map files provide a way to map between headers and modules, so that we can layer a module system on top of existing headers without changing those headers at all. This commit introduces the module map file parser and the module map that it generates, and wires up the module map file parser so that we'll automatically find module map files as part of header search. Note that we don't yet use the information stored in the module map. llvm-svn: 144402
2011-11-12 03:10:28 +08:00
/// \brief Whether an error occurred.
bool HadError;
Teach TargetInfo to hold on to the TargetOptions with which it was created. llvm-svn: 165943
2012-10-16 00:45:32 +08:00
Introduce basic support for parsing module map files. Module map files provide a way to map between headers and modules, so that we can layer a module system on top of existing headers without changing those headers at all. This commit introduces the module map file parser and the module map that it generates, and wires up the module map file parser so that we'll automatically find module map files as part of header search. Note that we don't yet use the information stored in the module map. llvm-svn: 144402
2011-11-12 03:10:28 +08:00
/// \brief Stores string data for the various string literals referenced
/// during parsing.
llvm::BumpPtrAllocator StringData;
/// \brief The current token.
MMToken Tok;
/// \brief The active module.
Promote ModuleMap::Module to a namespace-scope class in the Basic library, since modules cut across all of the libraries. Rename serialization::Module to serialization::ModuleFile to side-step the annoying naming conflict. Prune a bunch of ModuleMap.h includes that are no longer needed (most files only needed the Module type). llvm-svn: 145538
2011-12-01 07:21:26 +08:00
Module *ActiveModule;
[Modules] Add Darwin-specific compatibility module map parsing hacks 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. llvm-svn: 244912
2015-08-14 01:13:33 +08:00
/// \brief Whether a module uses the 'requires excluded' hack to mark its
/// contents as 'textual'.
///
/// On older Darwin SDK versions, 'requires excluded' is used to mark the
/// contents of the Darwin.C.excluded (assert.h) and Tcl.Private modules as
/// non-modular headers. For backwards compatibility, we continue to
/// support this idiom for just these modules, and map the headers to
/// 'textual' to match the original intent.
llvm::SmallPtrSet<Module *, 2> UsesRequiresExcludedHack;
Introduce basic support for parsing module map files. Module map files provide a way to map between headers and modules, so that we can layer a module system on top of existing headers without changing those headers at all. This commit introduces the module map file parser and the module map that it generates, and wires up the module map file parser so that we'll automatically find module map files as part of header search. Note that we don't yet use the information stored in the module map. llvm-svn: 144402
2011-11-12 03:10:28 +08:00
/// \brief Consume the current token and return its location.
SourceLocation consumeToken();
/// \brief Skip tokens until we reach the a token with the given kind
/// (or the end of the file).
void skipUntil(MMToken::TokenKind K);
Implement basic support for private headers in frameworks. In essence, when we load a module map (module.map) from a directory, also load a private module map (module_private.map) for that directory, if present. That private module map can inject a new submodule that captures private headers. llvm-svn: 146012
2011-12-07 10:23:45 +08:00
Remove useless 'llvm::' qualifier from names like StringRef and others that are brought into 'clang' namespace by clang/Basic/LLVM.h llvm-svn: 172323
2013-01-13 03:30:44 +08:00
typedef SmallVector<std::pair<std::string, SourceLocation>, 2> ModuleId;
Implement basic support for private headers in frameworks. In essence, when we load a module map (module.map) from a directory, also load a private module map (module_private.map) for that directory, if present. That private module map can inject a new submodule that captures private headers. llvm-svn: 146012
2011-12-07 10:23:45 +08:00
bool parseModuleId(ModuleId &Id);
Introduce basic support for parsing module map files. Module map files provide a way to map between headers and modules, so that we can layer a module system on top of existing headers without changing those headers at all. This commit introduces the module map file parser and the module map that it generates, and wires up the module map file parser so that we'll automatically find module map files as part of header search. Note that we don't yet use the information stored in the module map. llvm-svn: 144402
2011-11-12 03:10:28 +08:00
void parseModuleDecl();
Support for modular module-map-files This patch is the first step to make module-map-files modular (instead of requiring a single "module.map"-file per include directory). This step adds a new "extern module" declaration that enables module-map-files to reference one another along with a very basic implementation. The next steps are: * Combine this with the use-declaration (from http://llvm-reviews.chandlerc.com/D1546) in order to only load module map files required for a specific compilation. * Add an additional flag to start with a specific module-map-file (instead of requiring there to be at least one "module.map"). Review: http://llvm-reviews.chandlerc.com/D1637 llvm-svn: 190497
2013-09-11 15:20:44 +08:00
void parseExternModuleDecl();
Implement support for module requirements, which indicate the language features needed for a particular module to be available. This allows mixed-language modules, where certain headers only work under some language variants (e.g., in C++, std.tuple might only be available in C++11 mode). llvm-svn: 147387
2011-12-31 12:05:44 +08:00
void parseRequiresDecl();
This patch adds new private headers to the module map. Private headers may be included from within the module, but not from outside the module. llvm-svn: 184471
2013-06-21 05:14:14 +08:00
void parseHeaderDecl(clang::MMToken::TokenKind,
SourceLocation LeadingLoc);
Implement umbrella directories for modules, which are similar to umbrella headers in the sense that all of the headers within that directory (and eventually its subdirectories) are considered to be part of the module with that umbrella directory. However, unlike umbrella headers, which are expected to include all of the headers within their subdirectories, Clang will automatically include all of the headers it finds in the named subdirectory. The intent here is to allow a module map to trivially turn a subdirectory into a module, where the module's structure can mimic the directory structure. llvm-svn: 146165
2011-12-09 03:11:24 +08:00
void parseUmbrellaDirDecl(SourceLocation UmbrellaLoc);
Implementing parsing and resolution of module export declarations within module maps, which will (eventually) be used to re-export a module from another module. There are still some pieces missing, however. llvm-svn: 145665
2011-12-02 09:47:07 +08:00
void parseExportDecl();
Module use declarations (II) Review: http://llvm-reviews.chandlerc.com/D1546. I have picked up this patch form Lawrence (http://llvm-reviews.chandlerc.com/D1063) and did a few changes. From the original change description (updated as appropriate): This patch adds a check that ensures that modules only use modules they have so declared. To this end, it adds a statement on intended module use to the module.map grammar: use module-id A module can then only use headers from other modules if it 'uses' them. This enforcement is off by default, but may be turned on with the new option -fmodules-decluse. When enforcing the module semantics, we also need to consider a source file part of a module. This is achieved with a compiler option -fmodule-name=<module-id>. The compiler at present only applies restrictions to the module directly being built. llvm-svn: 191283
2013-09-24 17:14:14 +08:00
void parseUseDecl();
Implement parsing, AST, (de-)serialization, and placeholder global metadata for linking against the libraries/frameworks for imported modules. The module map language is extended with a new "link" directive that specifies what library or framework to link against when a module is imported, e.g., link "clangAST" or link framework "MyFramework" Importing the corresponding module (or any of its submodules) will eventually link against the named library/framework. For now, I've added some placeholder global metadata that encodes the imported libraries/frameworks, so that we can test that this information gets through to the IR. The format of the data is still under discussion. llvm-svn: 172437
2013-01-15 01:21:00 +08:00
void parseLinkDecl();
<rdar://problem/10796651> Introduce configuration macros into module maps. Configuration macros are macros that are intended to alter how a module works, such that we need to build different module variants for different values of these macros. A module can declare its configuration macros, in which case we will complain if the definition of a configation macro on the command line (or lack thereof) differs from the current preprocessor state at the point where the module is imported. This should eliminate some surprises when enabling modules, because "#define CONFIG_MACRO ..." followed by "#include <module/header.h>" would silently ignore the CONFIG_MACRO setting. At least it will no longer be silent about it. Configuration macros are eventually intended to help reduce the number of module variants that need to be built. When the list of configuration macros for a module is exhaustive, we only need to consider the settings for those macros when building/finding the module, which can help isolate modules for various project-specific -D flags that should never affect how modules are build (but currently do). llvm-svn: 177466
2013-03-20 08:22:05 +08:00
void parseConfigMacros();
<rdar://problem/12368093> Extend module maps with a 'conflict' declaration, and warn when a newly-imported module conflicts with an already-imported module. llvm-svn: 177577
2013-03-21 05:10:35 +08:00
void parseConflict();
Introduce inferred framework modules into the module map file, allowing a module map to be placed one level above the '.framework' directories to specify that all .frameworks within that directory can be inferred as framework modules. One can also specifically exclude frameworks known not to work. This makes explicit (and more restricted) behavior modules have had "forever", where *any* .framework was assumed to be able to be built as a module. That's not necessarily true, so we white-list directories (with exclusions) when those directories have been audited. llvm-svn: 167482
2012-11-07 03:39:40 +08:00
void parseInferredModuleDecl(bool Framework, bool Explicit);
Inherit attributes when infering a framework module If a module map contains framework module * [extern_c] {} We will now infer [extern_c] on the inferred framework modules (we already inferred [system] as a special case). llvm-svn: 225803
2015-01-14 01:47:44 +08:00
typedef ModuleMap::Attributes Attributes;
Revert r170500. It over-zealously converted *ALL* things named Attributes, which is wrong here. llvm-svn: 170721
2012-12-21 03:22:21 +08:00
bool parseOptionalAttributes(Attributes &Attrs);
Implement the notion of umbrella directories, which implicity cover all of the headers below that particular directory. Use umbrella directories as a clean way to deal with (1) directories/frameworks that don't have an umbrella header, but don't want to enumerate all of their headers, and (2) PrivateHeaders, which we never want to enumerate and want to keep separate from the main umbrella header. This also eliminates a little more of the "magic" for private headers, and frameworks in general. llvm-svn: 146235
2011-12-09 10:04:43 +08:00
Introduce basic support for parsing module map files. Module map files provide a way to map between headers and modules, so that we can layer a module system on top of existing headers without changing those headers at all. This commit introduces the module map file parser and the module map that it generates, and wires up the module map file parser so that we'll automatically find module map files as part of header search. Note that we don't yet use the information stored in the module map. llvm-svn: 144402
2011-11-12 03:10:28 +08:00
public:
explicit ModuleMapParser(Lexer &L, SourceManager &SourceMgr,
Teach TargetInfo to hold on to the TargetOptions with which it was created. llvm-svn: 165943
2012-10-16 00:45:32 +08:00
const TargetInfo *Target,
Introduce basic support for parsing module map files. Module map files provide a way to map between headers and modules, so that we can layer a module system on top of existing headers without changing those headers at all. This commit introduces the module map file parser and the module map that it generates, and wires up the module map file parser so that we'll automatically find module map files as part of header search. Note that we don't yet use the information stored in the module map. llvm-svn: 144402
2011-11-12 03:10:28 +08:00
DiagnosticsEngine &Diags,
Resolve the header files named in module map "header" and "umbrella" declarations to actual files. llvm-svn: 144408
2011-11-12 05:55:48 +08:00
ModuleMap &Map,
Allow multiple modules with the same name to coexist in the module cache To differentiate between two modules with the same name, we will consider the path the module map file that they are defined by* part of the ‘key’ for looking up the precompiled module (pcm file). Specifically, this patch renames the precompiled module (pcm) files from cache-path/<module hash>/Foo.pcm to cache-path/<module hash>/Foo-<hash of module map path>.pcm In addition, I’ve taught the ASTReader to re-resolve the names of imported modules during module loading so that if the header search context changes between when a module was originally built and when it is loaded we can rebuild it if necessary. For example, if module A imports module B first time: clang -I /path/to/A -I /path/to/B ... second time: clang -I /path/to/A -I /different/path/to/B ... will now rebuild A as expected. * in the case of inferred modules, we use the module map file that allowed the inference, not the __inferred_module.map file, since the inferred file path is the same for every inferred module. llvm-svn: 206201
2014-04-15 02:00:01 +08:00
const FileEntry *ModuleMapFile,
Back out my heinous hack that tricked the module generation mechanism into using non-absolute system includes (<foo>)... ... and introduce another hack that is simultaneously more heineous and more effective. We whitelist Clang-supplied headers that augment or override system headers (such as float.h, stdarg.h, and tgmath.h). For these headers, Clang does not provide a module mapping. Instead, a system-supplied module map can refer to these headers in a system module, and Clang will look both in its own include directory and wherever the system-supplied module map suggests, then adds either or both headers. The end result is that Clang-supplied headers get merged into the system-supplied module for the C standard library. As a drive-by, fix up a few dependencies in the _Builtin_instrinsics module. llvm-svn: 149611
2012-02-03 02:42:48 +08:00
const DirectoryEntry *Directory,
[Modules] If a module map resides in a system header directory, treat it as a system module. This prevents -pedantic from causing warnings in the system headers used to create modules. Fixes <rdar://problem/14201171>. llvm-svn: 184560
2013-06-22 00:28:10 +08:00
const DirectoryEntry *BuiltinIncludeDir,
bool IsSystem)
Teach TargetInfo to hold on to the TargetOptions with which it was created. llvm-svn: 165943
2012-10-16 00:45:32 +08:00
: L(L), SourceMgr(SourceMgr), Target(Target), Diags(Diags), Map(Map),
Allow multiple modules with the same name to coexist in the module cache To differentiate between two modules with the same name, we will consider the path the module map file that they are defined by* part of the ‘key’ for looking up the precompiled module (pcm file). Specifically, this patch renames the precompiled module (pcm) files from cache-path/<module hash>/Foo.pcm to cache-path/<module hash>/Foo-<hash of module map path>.pcm In addition, I’ve taught the ASTReader to re-resolve the names of imported modules during module loading so that if the header search context changes between when a module was originally built and when it is loaded we can rebuild it if necessary. For example, if module A imports module B first time: clang -I /path/to/A -I /path/to/B ... second time: clang -I /path/to/A -I /different/path/to/B ... will now rebuild A as expected. * in the case of inferred modules, we use the module map file that allowed the inference, not the __inferred_module.map file, since the inferred file path is the same for every inferred module. llvm-svn: 206201
2014-04-15 02:00:01 +08:00
ModuleMapFile(ModuleMapFile), Directory(Directory),
BuiltinIncludeDir(BuiltinIncludeDir), IsSystem(IsSystem),
[C++11] Use 'nullptr'. Lex edition. llvm-svn: 209083
2014-05-18 07:10:59 +08:00
HadError(false), ActiveModule(nullptr)
Introduce basic support for parsing module map files. Module map files provide a way to map between headers and modules, so that we can layer a module system on top of existing headers without changing those headers at all. This commit introduces the module map file parser and the module map that it generates, and wires up the module map file parser so that we'll automatically find module map files as part of header search. Note that we don't yet use the information stored in the module map. llvm-svn: 144402
2011-11-12 03:10:28 +08:00
{
Tok.clear();
consumeToken();
}
bool parseModuleMapFile();
};
Revert r240270 ("Fixed/added namespace ending comments using clang-tidy"). llvm-svn: 240353
2015-06-23 07:07:51 +08:00
}
Introduce basic support for parsing module map files. Module map files provide a way to map between headers and modules, so that we can layer a module system on top of existing headers without changing those headers at all. This commit introduces the module map file parser and the module map that it generates, and wires up the module map file parser so that we'll automatically find module map files as part of header search. Note that we don't yet use the information stored in the module map. llvm-svn: 144402
2011-11-12 03:10:28 +08:00
SourceLocation ModuleMapParser::consumeToken() {
retry:
SourceLocation Result = Tok.getLocation();
Tok.clear();
Token LToken;
L.LexFromRawLexer(LToken);
Tok.Location = LToken.getLocation().getRawEncoding();
switch (LToken.getKind()) {
Provide and use a safe Token::getRawIdentifier() accessor llvm-svn: 209061
2014-05-17 12:53:25 +08:00
case tok::raw_identifier: {
StringRef RI = LToken.getRawIdentifier();
Tok.StringData = RI.data();
Tok.StringLength = RI.size();
Tok.Kind = llvm::StringSwitch<MMToken::TokenKind>(RI)
<rdar://problem/10796651> Introduce configuration macros into module maps. Configuration macros are macros that are intended to alter how a module works, such that we need to build different module variants for different values of these macros. A module can declare its configuration macros, in which case we will complain if the definition of a configation macro on the command line (or lack thereof) differs from the current preprocessor state at the point where the module is imported. This should eliminate some surprises when enabling modules, because "#define CONFIG_MACRO ..." followed by "#include <module/header.h>" would silently ignore the CONFIG_MACRO setting. At least it will no longer be silent about it. Configuration macros are eventually intended to help reduce the number of module variants that need to be built. When the list of configuration macros for a module is exhaustive, we only need to consider the settings for those macros when building/finding the module, which can help isolate modules for various project-specific -D flags that should never affect how modules are build (but currently do). llvm-svn: 177466
2013-03-20 08:22:05 +08:00
.Case("config_macros", MMToken::ConfigMacros)
<rdar://problem/12368093> Extend module maps with a 'conflict' declaration, and warn when a newly-imported module conflicts with an already-imported module. llvm-svn: 177577
2013-03-21 05:10:35 +08:00
.Case("conflict", MMToken::Conflict)
Introduce the notion of excluded headers into the module map description. Previously, one could emulate this behavior by placing the header in an always-unavailable submodule, but Argyrios guilted me into expressing this idea properly. llvm-svn: 165921
2012-10-15 14:28:11 +08:00
.Case("exclude", MMToken::ExcludeKeyword)
Introduce basic support for parsing module map files. Module map files provide a way to map between headers and modules, so that we can layer a module system on top of existing headers without changing those headers at all. This commit introduces the module map file parser and the module map that it generates, and wires up the module map file parser so that we'll automatically find module map files as part of header search. Note that we don't yet use the information stored in the module map. llvm-svn: 144402
2011-11-12 03:10:28 +08:00
.Case("explicit", MMToken::ExplicitKeyword)
Implementing parsing and resolution of module export declarations within module maps, which will (eventually) be used to re-export a module from another module. There are still some pieces missing, however. llvm-svn: 145665
2011-12-02 09:47:07 +08:00
.Case("export", MMToken::ExportKeyword)
Support for modular module-map-files This patch is the first step to make module-map-files modular (instead of requiring a single "module.map"-file per include directory). This step adds a new "extern module" declaration that enables module-map-files to reference one another along with a very basic implementation. The next steps are: * Combine this with the use-declaration (from http://llvm-reviews.chandlerc.com/D1546) in order to only load module map files required for a specific compilation. * Add an additional flag to start with a specific module-map-file (instead of requiring there to be at least one "module.map"). Review: http://llvm-reviews.chandlerc.com/D1637 llvm-svn: 190497
2013-09-11 15:20:44 +08:00
.Case("extern", MMToken::ExternKeyword)
Add the notion of "framework" modules to module maps. Framework modules (obviously) describe frameworks, and understand the header layout of frameworks. llvm-svn: 144921
2011-11-18 06:09:43 +08:00
.Case("framework", MMToken::FrameworkKeyword)
<rdar://problem/10796651> Introduce configuration macros into module maps. Configuration macros are macros that are intended to alter how a module works, such that we need to build different module variants for different values of these macros. A module can declare its configuration macros, in which case we will complain if the definition of a configation macro on the command line (or lack thereof) differs from the current preprocessor state at the point where the module is imported. This should eliminate some surprises when enabling modules, because "#define CONFIG_MACRO ..." followed by "#include <module/header.h>" would silently ignore the CONFIG_MACRO setting. At least it will no longer be silent about it. Configuration macros are eventually intended to help reduce the number of module variants that need to be built. When the list of configuration macros for a module is exhaustive, we only need to consider the settings for those macros when building/finding the module, which can help isolate modules for various project-specific -D flags that should never affect how modules are build (but currently do). llvm-svn: 177466
2013-03-20 08:22:05 +08:00
.Case("header", MMToken::HeaderKeyword)
Implement parsing, AST, (de-)serialization, and placeholder global metadata for linking against the libraries/frameworks for imported modules. The module map language is extended with a new "link" directive that specifies what library or framework to link against when a module is imported, e.g., link "clangAST" or link framework "MyFramework" Importing the corresponding module (or any of its submodules) will eventually link against the named library/framework. For now, I've added some placeholder global metadata that encodes the imported libraries/frameworks, so that we can test that this information gets through to the IR. The format of the data is still under discussion. llvm-svn: 172437
2013-01-15 01:21:00 +08:00
.Case("link", MMToken::LinkKeyword)
Introduce basic support for parsing module map files. Module map files provide a way to map between headers and modules, so that we can layer a module system on top of existing headers without changing those headers at all. This commit introduces the module map file parser and the module map that it generates, and wires up the module map file parser so that we'll automatically find module map files as part of header search. Note that we don't yet use the information stored in the module map. llvm-svn: 144402
2011-11-12 03:10:28 +08:00
.Case("module", MMToken::ModuleKeyword)
This patch adds new private headers to the module map. Private headers may be included from within the module, but not from outside the module. llvm-svn: 184471
2013-06-21 05:14:14 +08:00
.Case("private", MMToken::PrivateKeyword)
Implement support for module requirements, which indicate the language features needed for a particular module to be available. This allows mixed-language modules, where certain headers only work under some language variants (e.g., in C++, std.tuple might only be available in C++11 mode). llvm-svn: 147387
2011-12-31 12:05:44 +08:00
.Case("requires", MMToken::RequiresKeyword)
[modules] Add support for 'textual header' directives. This allows a module to specify that it logically contains a file, but that said file is non-modular and intended for textual inclusion. This allows layering checks to work properly in the presence of such files. llvm-svn: 220448
2014-10-23 07:50:56 +08:00
.Case("textual", MMToken::TextualKeyword)
Introduce basic support for parsing module map files. Module map files provide a way to map between headers and modules, so that we can layer a module system on top of existing headers without changing those headers at all. This commit introduces the module map file parser and the module map that it generates, and wires up the module map file parser so that we'll automatically find module map files as part of header search. Note that we don't yet use the information stored in the module map. llvm-svn: 144402
2011-11-12 03:10:28 +08:00
.Case("umbrella", MMToken::UmbrellaKeyword)
Module use declarations (II) Review: http://llvm-reviews.chandlerc.com/D1546. I have picked up this patch form Lawrence (http://llvm-reviews.chandlerc.com/D1063) and did a few changes. From the original change description (updated as appropriate): This patch adds a check that ensures that modules only use modules they have so declared. To this end, it adds a statement on intended module use to the module.map grammar: use module-id A module can then only use headers from other modules if it 'uses' them. This enforcement is off by default, but may be turned on with the new option -fmodules-decluse. When enforcing the module semantics, we also need to consider a source file part of a module. This is achieved with a compiler option -fmodule-name=<module-id>. The compiler at present only applies restrictions to the module directly being built. llvm-svn: 191283
2013-09-24 17:14:14 +08:00
.Case("use", MMToken::UseKeyword)
Introduce basic support for parsing module map files. Module map files provide a way to map between headers and modules, so that we can layer a module system on top of existing headers without changing those headers at all. This commit introduces the module map file parser and the module map that it generates, and wires up the module map file parser so that we'll automatically find module map files as part of header search. Note that we don't yet use the information stored in the module map. llvm-svn: 144402
2011-11-12 03:10:28 +08:00
.Default(MMToken::Identifier);
break;
Provide and use a safe Token::getRawIdentifier() accessor llvm-svn: 209061
2014-05-17 12:53:25 +08:00
}
Implement support for module requirements, which indicate the language features needed for a particular module to be available. This allows mixed-language modules, where certain headers only work under some language variants (e.g., in C++, std.tuple might only be available in C++11 mode). llvm-svn: 147387
2011-12-31 12:05:44 +08:00
case tok::comma:
Tok.Kind = MMToken::Comma;
break;
Introduce basic support for parsing module map files. Module map files provide a way to map between headers and modules, so that we can layer a module system on top of existing headers without changing those headers at all. This commit introduces the module map file parser and the module map that it generates, and wires up the module map file parser so that we'll automatically find module map files as part of header search. Note that we don't yet use the information stored in the module map. llvm-svn: 144402
2011-11-12 03:10:28 +08:00
case tok::eof:
Tok.Kind = MMToken::EndOfFile;
break;
case tok::l_brace:
Tok.Kind = MMToken::LBrace;
break;
Introduce module attributes into the module map grammar, along with a single attribute ("system") that allows us to mark a module as being a "system" module. Each of the headers that makes up a system module is considered to be a system header, so that we (for example) suppress warnings there. If a module is being inferred for a framework, and that framework directory is within a system frameworks directory, infer it as a system framework. llvm-svn: 149143
2012-01-28 03:52:33 +08:00
case tok::l_square:
Tok.Kind = MMToken::LSquare;
break;
Implementing parsing and resolution of module export declarations within module maps, which will (eventually) be used to re-export a module from another module. There are still some pieces missing, however. llvm-svn: 145665
2011-12-02 09:47:07 +08:00
case tok::period:
Tok.Kind = MMToken::Period;
break;
Introduce basic support for parsing module map files. Module map files provide a way to map between headers and modules, so that we can layer a module system on top of existing headers without changing those headers at all. This commit introduces the module map file parser and the module map that it generates, and wires up the module map file parser so that we'll automatically find module map files as part of header search. Note that we don't yet use the information stored in the module map. llvm-svn: 144402
2011-11-12 03:10:28 +08:00
case tok::r_brace:
Tok.Kind = MMToken::RBrace;
break;
Introduce module attributes into the module map grammar, along with a single attribute ("system") that allows us to mark a module as being a "system" module. Each of the headers that makes up a system module is considered to be a system header, so that we (for example) suppress warnings there. If a module is being inferred for a framework, and that framework directory is within a system frameworks directory, infer it as a system framework. llvm-svn: 149143
2012-01-28 03:52:33 +08:00
case tok::r_square:
Tok.Kind = MMToken::RSquare;
break;
Implementing parsing and resolution of module export declarations within module maps, which will (eventually) be used to re-export a module from another module. There are still some pieces missing, however. llvm-svn: 145665
2011-12-02 09:47:07 +08:00
case tok::star:
Tok.Kind = MMToken::Star;
break;
Allow a new syntax in a module requires-declaration: requires ! feature The purpose of this is to allow (for instance) the module map for /usr/include to exclude <tgmath.h> and <complex.h> when building in C++ (these headers are instead provided by the C++ standard library in this case, and the glibc C <tgmath.h> header would otherwise try to include <complex.h>, resulting in a module cycle). llvm-svn: 193549
2013-10-29 06:18:19 +08:00
case tok::exclaim:
Tok.Kind = MMToken::Exclaim;
break;
Introduce basic support for parsing module map files. Module map files provide a way to map between headers and modules, so that we can layer a module system on top of existing headers without changing those headers at all. This commit introduces the module map file parser and the module map that it generates, and wires up the module map file parser so that we'll automatically find module map files as part of header search. Note that we don't yet use the information stored in the module map. llvm-svn: 144402
2011-11-12 03:10:28 +08:00
case tok::string_literal: {
User-defined literals: reject string and character UDLs in all places where the grammar requires a string-literal and not a user-defined-string-literal. The two constructs are still represented by the same TokenKind, in order to prevent a combinatorial explosion of different kinds of token. A flag on Token tracks whether a ud-suffix is present, in order to prevent clients from needing to look at the token's spelling. llvm-svn: 152098
2012-03-06 11:21:47 +08:00
if (LToken.hasUDSuffix()) {
Diags.Report(LToken.getLocation(), diag::err_invalid_string_udl);
HadError = true;
goto retry;
}
Introduce basic support for parsing module map files. Module map files provide a way to map between headers and modules, so that we can layer a module system on top of existing headers without changing those headers at all. This commit introduces the module map file parser and the module map that it generates, and wires up the module map file parser so that we'll automatically find module map files as part of header search. Note that we don't yet use the information stored in the module map. llvm-svn: 144402
2011-11-12 03:10:28 +08:00
// Parse the string literal.
LangOptions LangOpts;
Convert StringLiteralParser constructor to use ArrayRef instead of a pointer and count. llvm-svn: 211763
2014-06-26 12:58:39 +08:00
StringLiteralParser StringLiteral(LToken, SourceMgr, LangOpts, *Target);
Introduce basic support for parsing module map files. Module map files provide a way to map between headers and modules, so that we can layer a module system on top of existing headers without changing those headers at all. This commit introduces the module map file parser and the module map that it generates, and wires up the module map file parser so that we'll automatically find module map files as part of header search. Note that we don't yet use the information stored in the module map. llvm-svn: 144402
2011-11-12 03:10:28 +08:00
if (StringLiteral.hadError)
goto retry;
// Copy the string literal into our string data allocator.
unsigned Length = StringLiteral.GetStringLength();
char *Saved = StringData.Allocate<char>(Length + 1);
memcpy(Saved, StringLiteral.GetString().data(), Length);
Saved[Length] = 0;
// Form the token.
Tok.Kind = MMToken::StringLiteral;
Tok.StringData = Saved;
Tok.StringLength = Length;
break;
}
case tok::comment:
goto retry;
default:
Diags.Report(LToken.getLocation(), diag::err_mmap_unknown_token);
HadError = true;
goto retry;
}
return Result;
}
void ModuleMapParser::skipUntil(MMToken::TokenKind K) {
unsigned braceDepth = 0;
Introduce module attributes into the module map grammar, along with a single attribute ("system") that allows us to mark a module as being a "system" module. Each of the headers that makes up a system module is considered to be a system header, so that we (for example) suppress warnings there. If a module is being inferred for a framework, and that framework directory is within a system frameworks directory, infer it as a system framework. llvm-svn: 149143
2012-01-28 03:52:33 +08:00
unsigned squareDepth = 0;
Introduce basic support for parsing module map files. Module map files provide a way to map between headers and modules, so that we can layer a module system on top of existing headers without changing those headers at all. This commit introduces the module map file parser and the module map that it generates, and wires up the module map file parser so that we'll automatically find module map files as part of header search. Note that we don't yet use the information stored in the module map. llvm-svn: 144402
2011-11-12 03:10:28 +08:00
do {
switch (Tok.Kind) {
case MMToken::EndOfFile:
return;
case MMToken::LBrace:
Introduce module attributes into the module map grammar, along with a single attribute ("system") that allows us to mark a module as being a "system" module. Each of the headers that makes up a system module is considered to be a system header, so that we (for example) suppress warnings there. If a module is being inferred for a framework, and that framework directory is within a system frameworks directory, infer it as a system framework. llvm-svn: 149143
2012-01-28 03:52:33 +08:00
if (Tok.is(K) && braceDepth == 0 && squareDepth == 0)
Introduce basic support for parsing module map files. Module map files provide a way to map between headers and modules, so that we can layer a module system on top of existing headers without changing those headers at all. This commit introduces the module map file parser and the module map that it generates, and wires up the module map file parser so that we'll automatically find module map files as part of header search. Note that we don't yet use the information stored in the module map. llvm-svn: 144402
2011-11-12 03:10:28 +08:00
return;
++braceDepth;
break;
Introduce module attributes into the module map grammar, along with a single attribute ("system") that allows us to mark a module as being a "system" module. Each of the headers that makes up a system module is considered to be a system header, so that we (for example) suppress warnings there. If a module is being inferred for a framework, and that framework directory is within a system frameworks directory, infer it as a system framework. llvm-svn: 149143
2012-01-28 03:52:33 +08:00
case MMToken::LSquare:
if (Tok.is(K) && braceDepth == 0 && squareDepth == 0)
return;
++squareDepth;
break;
Introduce basic support for parsing module map files. Module map files provide a way to map between headers and modules, so that we can layer a module system on top of existing headers without changing those headers at all. This commit introduces the module map file parser and the module map that it generates, and wires up the module map file parser so that we'll automatically find module map files as part of header search. Note that we don't yet use the information stored in the module map. llvm-svn: 144402
2011-11-12 03:10:28 +08:00
case MMToken::RBrace:
if (braceDepth > 0)
--braceDepth;
else if (Tok.is(K))
return;
break;
Introduce module attributes into the module map grammar, along with a single attribute ("system") that allows us to mark a module as being a "system" module. Each of the headers that makes up a system module is considered to be a system header, so that we (for example) suppress warnings there. If a module is being inferred for a framework, and that framework directory is within a system frameworks directory, infer it as a system framework. llvm-svn: 149143
2012-01-28 03:52:33 +08:00
case MMToken::RSquare:
if (squareDepth > 0)
--squareDepth;
else if (Tok.is(K))
return;
break;
Introduce basic support for parsing module map files. Module map files provide a way to map between headers and modules, so that we can layer a module system on top of existing headers without changing those headers at all. This commit introduces the module map file parser and the module map that it generates, and wires up the module map file parser so that we'll automatically find module map files as part of header search. Note that we don't yet use the information stored in the module map. llvm-svn: 144402
2011-11-12 03:10:28 +08:00
default:
Introduce module attributes into the module map grammar, along with a single attribute ("system") that allows us to mark a module as being a "system" module. Each of the headers that makes up a system module is considered to be a system header, so that we (for example) suppress warnings there. If a module is being inferred for a framework, and that framework directory is within a system frameworks directory, infer it as a system framework. llvm-svn: 149143
2012-01-28 03:52:33 +08:00
if (braceDepth == 0 && squareDepth == 0 && Tok.is(K))
Introduce basic support for parsing module map files. Module map files provide a way to map between headers and modules, so that we can layer a module system on top of existing headers without changing those headers at all. This commit introduces the module map file parser and the module map that it generates, and wires up the module map file parser so that we'll automatically find module map files as part of header search. Note that we don't yet use the information stored in the module map. llvm-svn: 144402
2011-11-12 03:10:28 +08:00
return;
break;
}
consumeToken();
} while (true);
}
Implement basic support for private headers in frameworks. In essence, when we load a module map (module.map) from a directory, also load a private module map (module_private.map) for that directory, if present. That private module map can inject a new submodule that captures private headers. llvm-svn: 146012
2011-12-07 10:23:45 +08:00
/// \brief Parse a module-id.
///
/// module-id:
/// identifier
/// identifier '.' module-id
///
/// \returns true if an error occurred, false otherwise.
bool ModuleMapParser::parseModuleId(ModuleId &Id) {
Id.clear();
do {
Allow string literals as module names. In order to make the migration to modules easier, it seems to be helpful to allow a 1:1 mapping between target names of a current build system and the corresponding C++ modules. As such targets commonly contain characters like "-". ":" and "/", allowing arbitrary quote-escaped strings seems to be a straightforward option. After several offline discussions, the precise mechanisms for C++ module names especially regarding submodules and import statements has yet to be determined. Thus, this patch only enables string literals as names inside the module map files which can be used by automatic module import (through #include). Also improve the error message on missing use-declarations. llvm-svn: 196573
2013-12-06 17:25:54 +08:00
if (Tok.is(MMToken::Identifier) || Tok.is(MMToken::StringLiteral)) {
Implement basic support for private headers in frameworks. In essence, when we load a module map (module.map) from a directory, also load a private module map (module_private.map) for that directory, if present. That private module map can inject a new submodule that captures private headers. llvm-svn: 146012
2011-12-07 10:23:45 +08:00
Id.push_back(std::make_pair(Tok.getString(), Tok.getLocation()));
consumeToken();
} else {
Diags.Report(Tok.getLocation(), diag::err_mmap_expected_module_name);
return true;
}
if (!Tok.is(MMToken::Period))
break;
consumeToken();
} while (true);
return false;
}
Introduce module attributes into the module map grammar, along with a single attribute ("system") that allows us to mark a module as being a "system" module. Each of the headers that makes up a system module is considered to be a system header, so that we (for example) suppress warnings there. If a module is being inferred for a framework, and that framework directory is within a system frameworks directory, infer it as a system framework. llvm-svn: 149143
2012-01-28 03:52:33 +08:00
namespace {
/// \brief Enumerates the known attributes.
enum AttributeKind {
/// \brief An unknown attribute.
AT_unknown,
/// \brief The 'system' attribute.
<rdar://problem/10796651> Introduce configuration macros into module maps. Configuration macros are macros that are intended to alter how a module works, such that we need to build different module variants for different values of these macros. A module can declare its configuration macros, in which case we will complain if the definition of a configation macro on the command line (or lack thereof) differs from the current preprocessor state at the point where the module is imported. This should eliminate some surprises when enabling modules, because "#define CONFIG_MACRO ..." followed by "#include <module/header.h>" would silently ignore the CONFIG_MACRO setting. At least it will no longer be silent about it. Configuration macros are eventually intended to help reduce the number of module variants that need to be built. When the list of configuration macros for a module is exhaustive, we only need to consider the settings for those macros when building/finding the module, which can help isolate modules for various project-specific -D flags that should never affect how modules are build (but currently do). llvm-svn: 177466
2013-03-20 08:22:05 +08:00
AT_system,
Add [extern_c] attribute for modules, allowing a C module to be imported within an extern "C" block in C++ code. llvm-svn: 202615
2014-03-02 13:58:18 +08:00
/// \brief The 'extern_c' attribute.
AT_extern_c,
<rdar://problem/10796651> Introduce configuration macros into module maps. Configuration macros are macros that are intended to alter how a module works, such that we need to build different module variants for different values of these macros. A module can declare its configuration macros, in which case we will complain if the definition of a configation macro on the command line (or lack thereof) differs from the current preprocessor state at the point where the module is imported. This should eliminate some surprises when enabling modules, because "#define CONFIG_MACRO ..." followed by "#include <module/header.h>" would silently ignore the CONFIG_MACRO setting. At least it will no longer be silent about it. Configuration macros are eventually intended to help reduce the number of module variants that need to be built. When the list of configuration macros for a module is exhaustive, we only need to consider the settings for those macros when building/finding the module, which can help isolate modules for various project-specific -D flags that should never affect how modules are build (but currently do). llvm-svn: 177466
2013-03-20 08:22:05 +08:00
/// \brief The 'exhaustive' attribute.
[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
2016-10-21 09:41:56 +08:00
AT_exhaustive,
/// \brief The 'no_undeclared_includes' attribute.
AT_no_undeclared_includes
Introduce module attributes into the module map grammar, along with a single attribute ("system") that allows us to mark a module as being a "system" module. Each of the headers that makes up a system module is considered to be a system header, so that we (for example) suppress warnings there. If a module is being inferred for a framework, and that framework directory is within a system frameworks directory, infer it as a system framework. llvm-svn: 149143
2012-01-28 03:52:33 +08:00
};
Revert r240270 ("Fixed/added namespace ending comments using clang-tidy"). llvm-svn: 240353
2015-06-23 07:07:51 +08:00
}
Introduce module attributes into the module map grammar, along with a single attribute ("system") that allows us to mark a module as being a "system" module. Each of the headers that makes up a system module is considered to be a system header, so that we (for example) suppress warnings there. If a module is being inferred for a framework, and that framework directory is within a system frameworks directory, infer it as a system framework. llvm-svn: 149143
2012-01-28 03:52:33 +08:00
Introduce basic support for parsing module map files. Module map files provide a way to map between headers and modules, so that we can layer a module system on top of existing headers without changing those headers at all. This commit introduces the module map file parser and the module map that it generates, and wires up the module map file parser so that we'll automatically find module map files as part of header search. Note that we don't yet use the information stored in the module map. llvm-svn: 144402
2011-11-12 03:10:28 +08:00
/// \brief Parse a module declaration.
///
/// module-declaration:
Support for modular module-map-files This patch is the first step to make module-map-files modular (instead of requiring a single "module.map"-file per include directory). This step adds a new "extern module" declaration that enables module-map-files to reference one another along with a very basic implementation. The next steps are: * Combine this with the use-declaration (from http://llvm-reviews.chandlerc.com/D1546) in order to only load module map files required for a specific compilation. * Add an additional flag to start with a specific module-map-file (instead of requiring there to be at least one "module.map"). Review: http://llvm-reviews.chandlerc.com/D1637 llvm-svn: 190497
2013-09-11 15:20:44 +08:00
/// 'extern' 'module' module-id string-literal
Introduce module attributes into the module map grammar, along with a single attribute ("system") that allows us to mark a module as being a "system" module. Each of the headers that makes up a system module is considered to be a system header, so that we (for example) suppress warnings there. If a module is being inferred for a framework, and that framework directory is within a system frameworks directory, infer it as a system framework. llvm-svn: 149143
2012-01-28 03:52:33 +08:00
/// 'explicit'[opt] 'framework'[opt] 'module' module-id attributes[opt]
/// { module-member* }
///
Introduce basic support for parsing module map files. Module map files provide a way to map between headers and modules, so that we can layer a module system on top of existing headers without changing those headers at all. This commit introduces the module map file parser and the module map that it generates, and wires up the module map file parser so that we'll automatically find module map files as part of header search. Note that we don't yet use the information stored in the module map. llvm-svn: 144402
2011-11-12 03:10:28 +08:00
/// module-member:
Implement support for module requirements, which indicate the language features needed for a particular module to be available. This allows mixed-language modules, where certain headers only work under some language variants (e.g., in C++, std.tuple might only be available in C++11 mode). llvm-svn: 147387
2011-12-31 12:05:44 +08:00
/// requires-declaration
Introduce basic support for parsing module map files. Module map files provide a way to map between headers and modules, so that we can layer a module system on top of existing headers without changing those headers at all. This commit introduces the module map file parser and the module map that it generates, and wires up the module map file parser so that we'll automatically find module map files as part of header search. Note that we don't yet use the information stored in the module map. llvm-svn: 144402
2011-11-12 03:10:28 +08:00
/// header-declaration
Implement basic support for private headers in frameworks. In essence, when we load a module map (module.map) from a directory, also load a private module map (module_private.map) for that directory, if present. That private module map can inject a new submodule that captures private headers. llvm-svn: 146012
2011-12-07 10:23:45 +08:00
/// submodule-declaration
Implementing parsing and resolution of module export declarations within module maps, which will (eventually) be used to re-export a module from another module. There are still some pieces missing, however. llvm-svn: 145665
2011-12-02 09:47:07 +08:00
/// export-declaration
Implement parsing, AST, (de-)serialization, and placeholder global metadata for linking against the libraries/frameworks for imported modules. The module map language is extended with a new "link" directive that specifies what library or framework to link against when a module is imported, e.g., link "clangAST" or link framework "MyFramework" Importing the corresponding module (or any of its submodules) will eventually link against the named library/framework. For now, I've added some placeholder global metadata that encodes the imported libraries/frameworks, so that we can test that this information gets through to the IR. The format of the data is still under discussion. llvm-svn: 172437
2013-01-15 01:21:00 +08:00
/// link-declaration
Parse inferred submodules in module maps, track their contents in Module, and (de-)serialize this information. Semantics of inferred submodules to follow. llvm-svn: 145864
2011-12-06 06:27:44 +08:00
///
/// submodule-declaration:
/// module-declaration
/// inferred-submodule-declaration
Introduce basic support for parsing module map files. Module map files provide a way to map between headers and modules, so that we can layer a module system on top of existing headers without changing those headers at all. This commit introduces the module map file parser and the module map that it generates, and wires up the module map file parser so that we'll automatically find module map files as part of header search. Note that we don't yet use the information stored in the module map. llvm-svn: 144402
2011-11-12 03:10:28 +08:00
void ModuleMapParser::parseModuleDecl() {
Add the notion of "framework" modules to module maps. Framework modules (obviously) describe frameworks, and understand the header layout of frameworks. llvm-svn: 144921
2011-11-18 06:09:43 +08:00
assert(Tok.is(MMToken::ExplicitKeyword) || Tok.is(MMToken::ModuleKeyword) ||
Support for modular module-map-files This patch is the first step to make module-map-files modular (instead of requiring a single "module.map"-file per include directory). This step adds a new "extern module" declaration that enables module-map-files to reference one another along with a very basic implementation. The next steps are: * Combine this with the use-declaration (from http://llvm-reviews.chandlerc.com/D1546) in order to only load module map files required for a specific compilation. * Add an additional flag to start with a specific module-map-file (instead of requiring there to be at least one "module.map"). Review: http://llvm-reviews.chandlerc.com/D1637 llvm-svn: 190497
2013-09-11 15:20:44 +08:00
Tok.is(MMToken::FrameworkKeyword) || Tok.is(MMToken::ExternKeyword));
if (Tok.is(MMToken::ExternKeyword)) {
parseExternModuleDecl();
return;
}
Implement modules support for subframeworks (aka embedded frameworks). A submodule can now be labeled as a "framework", and header search will look into the appropriate Headers/PrivateHeaders subdirectories for named headers. llvm-svn: 145941
2011-12-07 01:16:41 +08:00
// Parse 'explicit' or 'framework' keyword, if present.
Implement basic support for private headers in frameworks. In essence, when we load a module map (module.map) from a directory, also load a private module map (module_private.map) for that directory, if present. That private module map can inject a new submodule that captures private headers. llvm-svn: 146012
2011-12-07 10:23:45 +08:00
SourceLocation ExplicitLoc;
Introduce basic support for parsing module map files. Module map files provide a way to map between headers and modules, so that we can layer a module system on top of existing headers without changing those headers at all. This commit introduces the module map file parser and the module map that it generates, and wires up the module map file parser so that we'll automatically find module map files as part of header search. Note that we don't yet use the information stored in the module map. llvm-svn: 144402
2011-11-12 03:10:28 +08:00
bool Explicit = false;
Implement modules support for subframeworks (aka embedded frameworks). A submodule can now be labeled as a "framework", and header search will look into the appropriate Headers/PrivateHeaders subdirectories for named headers. llvm-svn: 145941
2011-12-07 01:16:41 +08:00
bool Framework = false;
Add the notion of "framework" modules to module maps. Framework modules (obviously) describe frameworks, and understand the header layout of frameworks. llvm-svn: 144921
2011-11-18 06:09:43 +08:00
// Parse 'explicit' keyword, if present.
Implement modules support for subframeworks (aka embedded frameworks). A submodule can now be labeled as a "framework", and header search will look into the appropriate Headers/PrivateHeaders subdirectories for named headers. llvm-svn: 145941
2011-12-07 01:16:41 +08:00
if (Tok.is(MMToken::ExplicitKeyword)) {
Implement basic support for private headers in frameworks. In essence, when we load a module map (module.map) from a directory, also load a private module map (module_private.map) for that directory, if present. That private module map can inject a new submodule that captures private headers. llvm-svn: 146012
2011-12-07 10:23:45 +08:00
ExplicitLoc = consumeToken();
Introduce basic support for parsing module map files. Module map files provide a way to map between headers and modules, so that we can layer a module system on top of existing headers without changing those headers at all. This commit introduces the module map file parser and the module map that it generates, and wires up the module map file parser so that we'll automatically find module map files as part of header search. Note that we don't yet use the information stored in the module map. llvm-svn: 144402
2011-11-12 03:10:28 +08:00
Explicit = true;
}
Implement modules support for subframeworks (aka embedded frameworks). A submodule can now be labeled as a "framework", and header search will look into the appropriate Headers/PrivateHeaders subdirectories for named headers. llvm-svn: 145941
2011-12-07 01:16:41 +08:00
// Parse 'framework' keyword, if present.
if (Tok.is(MMToken::FrameworkKeyword)) {
consumeToken();
Framework = true;
}
Introduce basic support for parsing module map files. Module map files provide a way to map between headers and modules, so that we can layer a module system on top of existing headers without changing those headers at all. This commit introduces the module map file parser and the module map that it generates, and wires up the module map file parser so that we'll automatically find module map files as part of header search. Note that we don't yet use the information stored in the module map. llvm-svn: 144402
2011-11-12 03:10:28 +08:00
// Parse 'module' keyword.
if (!Tok.is(MMToken::ModuleKeyword)) {
Remove misleading error message llvm-svn: 145958
2011-12-07 03:57:48 +08:00
Diags.Report(Tok.getLocation(), diag::err_mmap_expected_module);
Introduce basic support for parsing module map files. Module map files provide a way to map between headers and modules, so that we can layer a module system on top of existing headers without changing those headers at all. This commit introduces the module map file parser and the module map that it generates, and wires up the module map file parser so that we'll automatically find module map files as part of header search. Note that we don't yet use the information stored in the module map. llvm-svn: 144402
2011-11-12 03:10:28 +08:00
consumeToken();
HadError = true;
return;
}
consumeToken(); // 'module' keyword
Parse inferred submodules in module maps, track their contents in Module, and (de-)serialize this information. Semantics of inferred submodules to follow. llvm-svn: 145864
2011-12-06 06:27:44 +08:00
// If we have a wildcard for the module name, this is an inferred submodule.
// Parse it.
if (Tok.is(MMToken::Star))
Introduce inferred framework modules into the module map file, allowing a module map to be placed one level above the '.framework' directories to specify that all .frameworks within that directory can be inferred as framework modules. One can also specifically exclude frameworks known not to work. This makes explicit (and more restricted) behavior modules have had "forever", where *any* .framework was assumed to be able to be built as a module. That's not necessarily true, so we white-list directories (with exclusions) when those directories have been audited. llvm-svn: 167482
2012-11-07 03:39:40 +08:00
return parseInferredModuleDecl(Framework, Explicit);
Introduce basic support for parsing module map files. Module map files provide a way to map between headers and modules, so that we can layer a module system on top of existing headers without changing those headers at all. This commit introduces the module map file parser and the module map that it generates, and wires up the module map file parser so that we'll automatically find module map files as part of header search. Note that we don't yet use the information stored in the module map. llvm-svn: 144402
2011-11-12 03:10:28 +08:00
// Parse the module name.
Implement basic support for private headers in frameworks. In essence, when we load a module map (module.map) from a directory, also load a private module map (module_private.map) for that directory, if present. That private module map can inject a new submodule that captures private headers. llvm-svn: 146012
2011-12-07 10:23:45 +08:00
ModuleId Id;
if (parseModuleId(Id)) {
HadError = true;
return;
}
Introduce inferred framework modules into the module map file, allowing a module map to be placed one level above the '.framework' directories to specify that all .frameworks within that directory can be inferred as framework modules. One can also specifically exclude frameworks known not to work. This makes explicit (and more restricted) behavior modules have had "forever", where *any* .framework was assumed to be able to be built as a module. That's not necessarily true, so we white-list directories (with exclusions) when those directories have been audited. llvm-svn: 167482
2012-11-07 03:39:40 +08:00
Implement basic support for private headers in frameworks. In essence, when we load a module map (module.map) from a directory, also load a private module map (module_private.map) for that directory, if present. That private module map can inject a new submodule that captures private headers. llvm-svn: 146012
2011-12-07 10:23:45 +08:00
if (ActiveModule) {
if (Id.size() > 1) {
Diags.Report(Id.front().second, diag::err_mmap_nested_submodule_id)
<< SourceRange(Id.front().second, Id.back().second);
HadError = true;
return;
}
} else if (Id.size() == 1 && Explicit) {
// Top-level modules can't be explicit.
Diags.Report(ExplicitLoc, diag::err_mmap_explicit_top_level);
Explicit = false;
ExplicitLoc = SourceLocation();
Introduce basic support for parsing module map files. Module map files provide a way to map between headers and modules, so that we can layer a module system on top of existing headers without changing those headers at all. This commit introduces the module map file parser and the module map that it generates, and wires up the module map file parser so that we'll automatically find module map files as part of header search. Note that we don't yet use the information stored in the module map. llvm-svn: 144402
2011-11-12 03:10:28 +08:00
HadError = true;
}
Implement basic support for private headers in frameworks. In essence, when we load a module map (module.map) from a directory, also load a private module map (module_private.map) for that directory, if present. That private module map can inject a new submodule that captures private headers. llvm-svn: 146012
2011-12-07 10:23:45 +08:00
Module *PreviousActiveModule = ActiveModule;
if (Id.size() > 1) {
// This module map defines a submodule. Go find the module of which it
// is a submodule.
[C++11] Use 'nullptr'. Lex edition. llvm-svn: 209083
2014-05-18 07:10:59 +08:00
ActiveModule = nullptr;
Verify all the module map files for a pcm are the same on load We already verified the primary module map file (either the one that defines the top-level module, or the one that allows inferring it if it is an inferred framework module). Now we also verify any other module map files that define submodules, such as when there is a module.private.modulemap file. llvm-svn: 215455
2014-08-13 00:42:33 +08:00
const Module *TopLevelModule = nullptr;
Implement basic support for private headers in frameworks. In essence, when we load a module map (module.map) from a directory, also load a private module map (module_private.map) for that directory, if present. That private module map can inject a new submodule that captures private headers. llvm-svn: 146012
2011-12-07 10:23:45 +08:00
for (unsigned I = 0, N = Id.size() - 1; I != N; ++I) {
if (Module *Next = Map.lookupModuleQualified(Id[I].first, ActiveModule)) {
Verify all the module map files for a pcm are the same on load We already verified the primary module map file (either the one that defines the top-level module, or the one that allows inferring it if it is an inferred framework module). Now we also verify any other module map files that define submodules, such as when there is a module.private.modulemap file. llvm-svn: 215455
2014-08-13 00:42:33 +08:00
if (I == 0)
TopLevelModule = Next;
Implement basic support for private headers in frameworks. In essence, when we load a module map (module.map) from a directory, also load a private module map (module_private.map) for that directory, if present. That private module map can inject a new submodule that captures private headers. llvm-svn: 146012
2011-12-07 10:23:45 +08:00
ActiveModule = Next;
continue;
}
if (ActiveModule) {
Diags.Report(Id[I].second, diag::err_mmap_missing_module_qualified)
Only allow streaming exactly type 'bool' to a DiagnosticBuilder, not anything that implicitly converts to 'bool' (such as pointers, and the first operand of ?:). Clean up issues found by this. Patch by Stephan Tolksdorf! llvm-svn: 203735
2014-03-13 07:36:42 +08:00
<< Id[I].first
<< ActiveModule->getTopLevelModule()->getFullModuleName();
Implement basic support for private headers in frameworks. In essence, when we load a module map (module.map) from a directory, also load a private module map (module_private.map) for that directory, if present. That private module map can inject a new submodule that captures private headers. llvm-svn: 146012
2011-12-07 10:23:45 +08:00
} else {
Diags.Report(Id[I].second, diag::err_mmap_expected_module_name);
}
HadError = true;
return;
}
Verify all the module map files for a pcm are the same on load We already verified the primary module map file (either the one that defines the top-level module, or the one that allows inferring it if it is an inferred framework module). Now we also verify any other module map files that define submodules, such as when there is a module.private.modulemap file. llvm-svn: 215455
2014-08-13 00:42:33 +08:00
if (ModuleMapFile != Map.getContainingModuleMapFile(TopLevelModule)) {
assert(ModuleMapFile != Map.getModuleMapFileForUniquing(TopLevelModule) &&
"submodule defined in same file as 'module *' that allowed its "
"top-level module");
Map.addAdditionalModuleMapFile(TopLevelModule, ModuleMapFile);
}
}
Implement basic support for private headers in frameworks. In essence, when we load a module map (module.map) from a directory, also load a private module map (module_private.map) for that directory, if present. That private module map can inject a new submodule that captures private headers. llvm-svn: 146012
2011-12-07 10:23:45 +08:00
StringRef ModuleName = Id.back().first;
SourceLocation ModuleNameLoc = Id.back().second;
Introduce basic support for parsing module map files. Module map files provide a way to map between headers and modules, so that we can layer a module system on top of existing headers without changing those headers at all. This commit introduces the module map file parser and the module map that it generates, and wires up the module map file parser so that we'll automatically find module map files as part of header search. Note that we don't yet use the information stored in the module map. llvm-svn: 144402
2011-11-12 03:10:28 +08:00
Introduce module attributes into the module map grammar, along with a single attribute ("system") that allows us to mark a module as being a "system" module. Each of the headers that makes up a system module is considered to be a system header, so that we (for example) suppress warnings there. If a module is being inferred for a framework, and that framework directory is within a system frameworks directory, infer it as a system framework. llvm-svn: 149143
2012-01-28 03:52:33 +08:00
// Parse the optional attribute list.
Revert r170500. It over-zealously converted *ALL* things named Attributes, which is wrong here. llvm-svn: 170721
2012-12-21 03:22:21 +08:00
Attributes Attrs;
[Modules] Don't swallow errors when parsing optional attributes. Differential Revision: http://reviews.llvm.org/D17787 llvm-svn: 262789
2016-03-06 12:20:05 +08:00
if (parseOptionalAttributes(Attrs))
return;
Introduce module attributes into the module map grammar, along with a single attribute ("system") that allows us to mark a module as being a "system" module. Each of the headers that makes up a system module is considered to be a system header, so that we (for example) suppress warnings there. If a module is being inferred for a framework, and that framework directory is within a system frameworks directory, infer it as a system framework. llvm-svn: 149143
2012-01-28 03:52:33 +08:00
Introduce basic support for parsing module map files. Module map files provide a way to map between headers and modules, so that we can layer a module system on top of existing headers without changing those headers at all. This commit introduces the module map file parser and the module map that it generates, and wires up the module map file parser so that we'll automatically find module map files as part of header search. Note that we don't yet use the information stored in the module map. llvm-svn: 144402
2011-11-12 03:10:28 +08:00
// Parse the opening brace.
if (!Tok.is(MMToken::LBrace)) {
Diags.Report(Tok.getLocation(), diag::err_mmap_expected_lbrace)
<< ModuleName;
HadError = true;
return;
}
SourceLocation LBraceLoc = consumeToken();
// Determine whether this (sub)module has already been defined.
Store the submodules of a module in source order, as they are stored in the module map. This provides a bit more predictability for the user, as well as eliminating the need to sort the submodules when serializing them. llvm-svn: 147564
2012-01-05 07:32:19 +08:00
if (Module *Existing = Map.lookupModuleQualified(ModuleName, ActiveModule)) {
If we already have a definition for a top-level module that we deserialized from a module file, don't bother parsing a new definition llvm-svn: 147574
2012-01-05 08:12:00 +08:00
if (Existing->DefinitionLoc.isInvalid() && !ActiveModule) {
// Skip the module definition.
skipUntil(MMToken::RBrace);
if (Tok.is(MMToken::RBrace))
consumeToken();
else {
Diags.Report(Tok.getLocation(), diag::err_mmap_expected_rbrace);
Diags.Report(LBraceLoc, diag::note_mmap_lbrace_match);
HadError = true;
}
return;
}
Introduce basic support for parsing module map files. Module map files provide a way to map between headers and modules, so that we can layer a module system on top of existing headers without changing those headers at all. This commit introduces the module map file parser and the module map that it generates, and wires up the module map file parser so that we'll automatically find module map files as part of header search. Note that we don't yet use the information stored in the module map. llvm-svn: 144402
2011-11-12 03:10:28 +08:00
Diags.Report(ModuleNameLoc, diag::err_mmap_module_redefinition)
<< ModuleName;
Store the submodules of a module in source order, as they are stored in the module map. This provides a bit more predictability for the user, as well as eliminating the need to sort the submodules when serializing them. llvm-svn: 147564
2012-01-05 07:32:19 +08:00
Diags.Report(Existing->DefinitionLoc, diag::note_mmap_prev_definition);
Introduce basic support for parsing module map files. Module map files provide a way to map between headers and modules, so that we can layer a module system on top of existing headers without changing those headers at all. This commit introduces the module map file parser and the module map that it generates, and wires up the module map file parser so that we'll automatically find module map files as part of header search. Note that we don't yet use the information stored in the module map. llvm-svn: 144402
2011-11-12 03:10:28 +08:00
// Skip the module definition.
skipUntil(MMToken::RBrace);
if (Tok.is(MMToken::RBrace))
consumeToken();
HadError = true;
return;
}
// Start defining this module.
Refactor the module map file used for uniquing a module name out of class Module. It's almost always going to be the same as getContainingModule() for top-level modules, so just add a map to cover the remaining cases. This lets us do less bookkeeping to keep the ModuleMap fields up to date. llvm-svn: 215268
2014-08-09 08:57:23 +08:00
ActiveModule = Map.findOrCreateModule(ModuleName, ActiveModule, Framework,
Explicit).first;
Store the submodules of a module in source order, as they are stored in the module map. This provides a bit more predictability for the user, as well as eliminating the need to sort the submodules when serializing them. llvm-svn: 147564
2012-01-05 07:32:19 +08:00
ActiveModule->DefinitionLoc = ModuleNameLoc;
[Modules] If a module map resides in a system header directory, treat it as a system module. This prevents -pedantic from causing warnings in the system headers used to create modules. Fixes <rdar://problem/14201171>. llvm-svn: 184560
2013-06-22 00:28:10 +08:00
if (Attrs.IsSystem || IsSystem)
Introduce module attributes into the module map grammar, along with a single attribute ("system") that allows us to mark a module as being a "system" module. Each of the headers that makes up a system module is considered to be a system header, so that we (for example) suppress warnings there. If a module is being inferred for a framework, and that framework directory is within a system frameworks directory, infer it as a system framework. llvm-svn: 149143
2012-01-28 03:52:33 +08:00
ActiveModule->IsSystem = true;
Add [extern_c] attribute for modules, allowing a C module to be imported within an extern "C" block in C++ code. llvm-svn: 202615
2014-03-02 13:58:18 +08:00
if (Attrs.IsExternC)
ActiveModule->IsExternC = true;
[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
2016-10-21 09:41:56 +08:00
if (Attrs.NoUndeclaredIncludes ||
(!ActiveModule->Parent && ModuleName == "Darwin"))
ActiveModule->NoUndeclaredIncludes = true;
[modules] Track how 'header' directives were written in module map files, rather than trying to extract this information from the FileEntry after the fact. This has a number of beneficial effects. For instance, diagnostic messages for failed module builds give a path relative to the "module root" rather than an absolute file path, and the contents of the module includes file is no longer dependent on what files the including TU happened to inspect prior to triggering the module build. llvm-svn: 223095
2014-12-02 08:08:08 +08:00
ActiveModule->Directory = Directory;
Add [extern_c] attribute for modules, allowing a C module to be imported within an extern "C" block in C++ code. llvm-svn: 202615
2014-03-02 13:58:18 +08:00
[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
2016-12-21 08:24:39 +08:00
if (!ActiveModule->Parent) {
StringRef MapFileName(ModuleMapFile->getName());
if (MapFileName.endswith("module.private.modulemap") ||
MapFileName.endswith("module_private.map")) {
// Adding a top-level module from a private modulemap is likely a
// user error; we check to see if there's another top-level module
// defined in the non-private map in the same dir, and if so emit a
// warning.
for (auto E = Map.module_begin(); E != Map.module_end(); ++E) {
auto const *M = E->getValue();
if (!M->Parent &&
M->Directory == ActiveModule->Directory &&
M->Name != ActiveModule->Name) {
Diags.Report(ActiveModule->DefinitionLoc,
diag::warn_mmap_mismatched_top_level_private)
<< ActiveModule->Name << M->Name;
// The pattern we're defending against here is typically due to
// a module named FooPrivate which is supposed to be a submodule
// called Foo.Private. Emit a fixit in that case.
auto D =
Diags.Report(ActiveModule->DefinitionLoc,
diag::note_mmap_rename_top_level_private_as_submodule);
D << ActiveModule->Name << M->Name;
StringRef Bad(ActiveModule->Name);
if (Bad.consume_back("Private")) {
SmallString<128> Fixed = Bad;
Fixed.append(".Private");
D << FixItHint::CreateReplacement(ActiveModule->DefinitionLoc,
Fixed);
}
break;
}
}
}
}
Introduce basic support for parsing module map files. Module map files provide a way to map between headers and modules, so that we can layer a module system on top of existing headers without changing those headers at all. This commit introduces the module map file parser and the module map that it generates, and wires up the module map file parser so that we'll automatically find module map files as part of header search. Note that we don't yet use the information stored in the module map. llvm-svn: 144402
2011-11-12 03:10:28 +08:00
bool Done = false;
do {
switch (Tok.Kind) {
case MMToken::EndOfFile:
case MMToken::RBrace:
Done = true;
break;
<rdar://problem/10796651> Introduce configuration macros into module maps. Configuration macros are macros that are intended to alter how a module works, such that we need to build different module variants for different values of these macros. A module can declare its configuration macros, in which case we will complain if the definition of a configation macro on the command line (or lack thereof) differs from the current preprocessor state at the point where the module is imported. This should eliminate some surprises when enabling modules, because "#define CONFIG_MACRO ..." followed by "#include <module/header.h>" would silently ignore the CONFIG_MACRO setting. At least it will no longer be silent about it. Configuration macros are eventually intended to help reduce the number of module variants that need to be built. When the list of configuration macros for a module is exhaustive, we only need to consider the settings for those macros when building/finding the module, which can help isolate modules for various project-specific -D flags that should never affect how modules are build (but currently do). llvm-svn: 177466
2013-03-20 08:22:05 +08:00
case MMToken::ConfigMacros:
parseConfigMacros();
break;
<rdar://problem/12368093> Extend module maps with a 'conflict' declaration, and warn when a newly-imported module conflicts with an already-imported module. llvm-svn: 177577
2013-03-21 05:10:35 +08:00
case MMToken::Conflict:
parseConflict();
break;
Introduce basic support for parsing module map files. Module map files provide a way to map between headers and modules, so that we can layer a module system on top of existing headers without changing those headers at all. This commit introduces the module map file parser and the module map that it generates, and wires up the module map file parser so that we'll automatically find module map files as part of header search. Note that we don't yet use the information stored in the module map. llvm-svn: 144402
2011-11-12 03:10:28 +08:00
case MMToken::ExplicitKeyword:
Support for modular module-map-files This patch is the first step to make module-map-files modular (instead of requiring a single "module.map"-file per include directory). This step adds a new "extern module" declaration that enables module-map-files to reference one another along with a very basic implementation. The next steps are: * Combine this with the use-declaration (from http://llvm-reviews.chandlerc.com/D1546) in order to only load module map files required for a specific compilation. * Add an additional flag to start with a specific module-map-file (instead of requiring there to be at least one "module.map"). Review: http://llvm-reviews.chandlerc.com/D1637 llvm-svn: 190497
2013-09-11 15:20:44 +08:00
case MMToken::ExternKeyword:
Implement modules support for subframeworks (aka embedded frameworks). A submodule can now be labeled as a "framework", and header search will look into the appropriate Headers/PrivateHeaders subdirectories for named headers. llvm-svn: 145941
2011-12-07 01:16:41 +08:00
case MMToken::FrameworkKeyword:
Introduce basic support for parsing module map files. Module map files provide a way to map between headers and modules, so that we can layer a module system on top of existing headers without changing those headers at all. This commit introduces the module map file parser and the module map that it generates, and wires up the module map file parser so that we'll automatically find module map files as part of header search. Note that we don't yet use the information stored in the module map. llvm-svn: 144402
2011-11-12 03:10:28 +08:00
case MMToken::ModuleKeyword:
parseModuleDecl();
break;
Support for modular module-map-files This patch is the first step to make module-map-files modular (instead of requiring a single "module.map"-file per include directory). This step adds a new "extern module" declaration that enables module-map-files to reference one another along with a very basic implementation. The next steps are: * Combine this with the use-declaration (from http://llvm-reviews.chandlerc.com/D1546) in order to only load module map files required for a specific compilation. * Add an additional flag to start with a specific module-map-file (instead of requiring there to be at least one "module.map"). Review: http://llvm-reviews.chandlerc.com/D1637 llvm-svn: 190497
2013-09-11 15:20:44 +08:00
Implementing parsing and resolution of module export declarations within module maps, which will (eventually) be used to re-export a module from another module. There are still some pieces missing, however. llvm-svn: 145665
2011-12-02 09:47:07 +08:00
case MMToken::ExportKeyword:
parseExportDecl();
break;
Module use declarations (II) Review: http://llvm-reviews.chandlerc.com/D1546. I have picked up this patch form Lawrence (http://llvm-reviews.chandlerc.com/D1063) and did a few changes. From the original change description (updated as appropriate): This patch adds a check that ensures that modules only use modules they have so declared. To this end, it adds a statement on intended module use to the module.map grammar: use module-id A module can then only use headers from other modules if it 'uses' them. This enforcement is off by default, but may be turned on with the new option -fmodules-decluse. When enforcing the module semantics, we also need to consider a source file part of a module. This is achieved with a compiler option -fmodule-name=<module-id>. The compiler at present only applies restrictions to the module directly being built. llvm-svn: 191283
2013-09-24 17:14:14 +08:00
case MMToken::UseKeyword:
parseUseDecl();
break;
Implementing parsing and resolution of module export declarations within module maps, which will (eventually) be used to re-export a module from another module. There are still some pieces missing, however. llvm-svn: 145665
2011-12-02 09:47:07 +08:00
Implement support for module requirements, which indicate the language features needed for a particular module to be available. This allows mixed-language modules, where certain headers only work under some language variants (e.g., in C++, std.tuple might only be available in C++11 mode). llvm-svn: 147387
2011-12-31 12:05:44 +08:00
case MMToken::RequiresKeyword:
parseRequiresDecl();
break;
[modules] Support combining 'textual' with 'private'. llvm-svn: 220589
2014-10-25 04:23:01 +08:00
case MMToken::TextualKeyword:
parseHeaderDecl(MMToken::TextualKeyword, consumeToken());
[modules] Add support for 'textual header' directives. This allows a module to specify that it logically contains a file, but that said file is non-modular and intended for textual inclusion. This allows layering checks to work properly in the presence of such files. llvm-svn: 220448
2014-10-23 07:50:56 +08:00
break;
Implement umbrella directories for modules, which are similar to umbrella headers in the sense that all of the headers within that directory (and eventually its subdirectories) are considered to be part of the module with that umbrella directory. However, unlike umbrella headers, which are expected to include all of the headers within their subdirectories, Clang will automatically include all of the headers it finds in the named subdirectory. The intent here is to allow a module map to trivially turn a subdirectory into a module, where the module's structure can mimic the directory structure. llvm-svn: 146165
2011-12-09 03:11:24 +08:00
case MMToken::UmbrellaKeyword: {
SourceLocation UmbrellaLoc = consumeToken();
if (Tok.is(MMToken::HeaderKeyword))
This patch adds new private headers to the module map. Private headers may be included from within the module, but not from outside the module. llvm-svn: 184471
2013-06-21 05:14:14 +08:00
parseHeaderDecl(MMToken::UmbrellaKeyword, UmbrellaLoc);
Implement umbrella directories for modules, which are similar to umbrella headers in the sense that all of the headers within that directory (and eventually its subdirectories) are considered to be part of the module with that umbrella directory. However, unlike umbrella headers, which are expected to include all of the headers within their subdirectories, Clang will automatically include all of the headers it finds in the named subdirectory. The intent here is to allow a module map to trivially turn a subdirectory into a module, where the module's structure can mimic the directory structure. llvm-svn: 146165
2011-12-09 03:11:24 +08:00
else
parseUmbrellaDirDecl(UmbrellaLoc);
Introduce basic support for parsing module map files. Module map files provide a way to map between headers and modules, so that we can layer a module system on top of existing headers without changing those headers at all. This commit introduces the module map file parser and the module map that it generates, and wires up the module map file parser so that we'll automatically find module map files as part of header search. Note that we don't yet use the information stored in the module map. llvm-svn: 144402
2011-11-12 03:10:28 +08:00
break;
Implement umbrella directories for modules, which are similar to umbrella headers in the sense that all of the headers within that directory (and eventually its subdirectories) are considered to be part of the module with that umbrella directory. However, unlike umbrella headers, which are expected to include all of the headers within their subdirectories, Clang will automatically include all of the headers it finds in the named subdirectory. The intent here is to allow a module map to trivially turn a subdirectory into a module, where the module's structure can mimic the directory structure. llvm-svn: 146165
2011-12-09 03:11:24 +08:00
}
[modules] Support combining 'textual' with 'private'. llvm-svn: 220589
2014-10-25 04:23:01 +08:00
case MMToken::ExcludeKeyword:
parseHeaderDecl(MMToken::ExcludeKeyword, consumeToken());
Introduce the notion of excluded headers into the module map description. Previously, one could emulate this behavior by placing the header in an always-unavailable submodule, but Argyrios guilted me into expressing this idea properly. llvm-svn: 165921
2012-10-15 14:28:11 +08:00
break;
[modules] Support combining 'textual' with 'private'. llvm-svn: 220589
2014-10-25 04:23:01 +08:00
case MMToken::PrivateKeyword:
parseHeaderDecl(MMToken::PrivateKeyword, consumeToken());
This patch adds new private headers to the module map. Private headers may be included from within the module, but not from outside the module. llvm-svn: 184471
2013-06-21 05:14:14 +08:00
break;
[modules] Support combining 'textual' with 'private'. llvm-svn: 220589
2014-10-25 04:23:01 +08:00
Tweak the syntax of umbrella headers, so that "umbrella" is treated as a modifier for a header declarartion, e.g., umbrella header "headername" Collapse the umbrella-handling code in the parser into the header-handling code, so we don't duplicate the header-search logic. llvm-svn: 146159
2011-12-09 02:00:48 +08:00
case MMToken::HeaderKeyword:
[modules] Support combining 'textual' with 'private'. llvm-svn: 220589
2014-10-25 04:23:01 +08:00
parseHeaderDecl(MMToken::HeaderKeyword, consumeToken());
Introduce basic support for parsing module map files. Module map files provide a way to map between headers and modules, so that we can layer a module system on top of existing headers without changing those headers at all. This commit introduces the module map file parser and the module map that it generates, and wires up the module map file parser so that we'll automatically find module map files as part of header search. Note that we don't yet use the information stored in the module map. llvm-svn: 144402
2011-11-12 03:10:28 +08:00
break;
Implement parsing, AST, (de-)serialization, and placeholder global metadata for linking against the libraries/frameworks for imported modules. The module map language is extended with a new "link" directive that specifies what library or framework to link against when a module is imported, e.g., link "clangAST" or link framework "MyFramework" Importing the corresponding module (or any of its submodules) will eventually link against the named library/framework. For now, I've added some placeholder global metadata that encodes the imported libraries/frameworks, so that we can test that this information gets through to the IR. The format of the data is still under discussion. llvm-svn: 172437
2013-01-15 01:21:00 +08:00
case MMToken::LinkKeyword:
parseLinkDecl();
break;
Introduce basic support for parsing module map files. Module map files provide a way to map between headers and modules, so that we can layer a module system on top of existing headers without changing those headers at all. This commit introduces the module map file parser and the module map that it generates, and wires up the module map file parser so that we'll automatically find module map files as part of header search. Note that we don't yet use the information stored in the module map. llvm-svn: 144402
2011-11-12 03:10:28 +08:00
default:
Diags.Report(Tok.getLocation(), diag::err_mmap_expected_member);
consumeToken();
break;
}
} while (!Done);
if (Tok.is(MMToken::RBrace))
consumeToken();
else {
Diags.Report(Tok.getLocation(), diag::err_mmap_expected_rbrace);
Diags.Report(LBraceLoc, diag::note_mmap_lbrace_match);
HadError = true;
}
Infer "link" lines for top-level frameworks. Essentially, a framework will have a shared library with the same name as its framework (and no suffix!) within its .framework directory. Detect this both when inferring the whole top-level framework and when parsing a module map. llvm-svn: 172439
2013-01-15 01:57:51 +08:00
// If the active module is a top-level framework, and there are no link
// libraries, automatically link against the framework.
if (ActiveModule->IsFramework && !ActiveModule->isSubFramework() &&
ActiveModule->LinkLibraries.empty()) {
inferFrameworkLink(ActiveModule, Directory, SourceMgr.getFileManager());
}
Don't build modules with (submodules with) missing headers Unless they are in submodules that aren't available anyway, due to requirements not being met. Also, mark children as unavailable when the parent is. llvm-svn: 206664
2014-04-19 06:07:31 +08:00
// If the module meets all requirements but is still unavailable, mark the
// whole tree as unavailable to prevent it from building.
if (!ActiveModule->IsAvailable && !ActiveModule->IsMissingRequirement &&
ActiveModule->Parent) {
ActiveModule->getTopLevelModule()->markUnavailable();
ActiveModule->getTopLevelModule()->MissingHeaders.append(
ActiveModule->MissingHeaders.begin(), ActiveModule->MissingHeaders.end());
}
Implement basic support for private headers in frameworks. In essence, when we load a module map (module.map) from a directory, also load a private module map (module_private.map) for that directory, if present. That private module map can inject a new submodule that captures private headers. llvm-svn: 146012
2011-12-07 10:23:45 +08:00
// We're done parsing this module. Pop back to the previous module.
ActiveModule = PreviousActiveModule;
Introduce basic support for parsing module map files. Module map files provide a way to map between headers and modules, so that we can layer a module system on top of existing headers without changing those headers at all. This commit introduces the module map file parser and the module map that it generates, and wires up the module map file parser so that we'll automatically find module map files as part of header search. Note that we don't yet use the information stored in the module map. llvm-svn: 144402
2011-11-12 03:10:28 +08:00
}
Implement modules support for subframeworks (aka embedded frameworks). A submodule can now be labeled as a "framework", and header search will look into the appropriate Headers/PrivateHeaders subdirectories for named headers. llvm-svn: 145941
2011-12-07 01:16:41 +08:00
Support for modular module-map-files This patch is the first step to make module-map-files modular (instead of requiring a single "module.map"-file per include directory). This step adds a new "extern module" declaration that enables module-map-files to reference one another along with a very basic implementation. The next steps are: * Combine this with the use-declaration (from http://llvm-reviews.chandlerc.com/D1546) in order to only load module map files required for a specific compilation. * Add an additional flag to start with a specific module-map-file (instead of requiring there to be at least one "module.map"). Review: http://llvm-reviews.chandlerc.com/D1637 llvm-svn: 190497
2013-09-11 15:20:44 +08:00
/// \brief Parse an extern module declaration.
///
/// extern module-declaration:
/// 'extern' 'module' module-id string-literal
void ModuleMapParser::parseExternModuleDecl() {
assert(Tok.is(MMToken::ExternKeyword));
[modules] When diagnosing errors in module map files found by 'extern module' declarations, show how we got to that module map file. llvm-svn: 242105
2015-07-14 10:06:01 +08:00
SourceLocation ExternLoc = consumeToken(); // 'extern' keyword
Support for modular module-map-files This patch is the first step to make module-map-files modular (instead of requiring a single "module.map"-file per include directory). This step adds a new "extern module" declaration that enables module-map-files to reference one another along with a very basic implementation. The next steps are: * Combine this with the use-declaration (from http://llvm-reviews.chandlerc.com/D1546) in order to only load module map files required for a specific compilation. * Add an additional flag to start with a specific module-map-file (instead of requiring there to be at least one "module.map"). Review: http://llvm-reviews.chandlerc.com/D1637 llvm-svn: 190497
2013-09-11 15:20:44 +08:00
// Parse 'module' keyword.
if (!Tok.is(MMToken::ModuleKeyword)) {
Diags.Report(Tok.getLocation(), diag::err_mmap_expected_module);
consumeToken();
HadError = true;
return;
}
consumeToken(); // 'module' keyword
// Parse the module name.
ModuleId Id;
if (parseModuleId(Id)) {
HadError = true;
return;
}
// Parse the referenced module map file name.
if (!Tok.is(MMToken::StringLiteral)) {
Diags.Report(Tok.getLocation(), diag::err_mmap_expected_mmap_file);
HadError = true;
return;
}
std::string FileName = Tok.getString();
consumeToken(); // filename
StringRef FileNameRef = FileName;
SmallString<128> ModuleMapFileName;
if (llvm::sys::path::is_relative(FileNameRef)) {
ModuleMapFileName += Directory->getName();
llvm::sys::path::append(ModuleMapFileName, FileName);
Remove many superfluous SmallString::str() calls. 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. llvm-svn: 232622
2015-03-18 18:17:07 +08:00
FileNameRef = ModuleMapFileName;
Support for modular module-map-files This patch is the first step to make module-map-files modular (instead of requiring a single "module.map"-file per include directory). This step adds a new "extern module" declaration that enables module-map-files to reference one another along with a very basic implementation. The next steps are: * Combine this with the use-declaration (from http://llvm-reviews.chandlerc.com/D1546) in order to only load module map files required for a specific compilation. * Add an additional flag to start with a specific module-map-file (instead of requiring there to be at least one "module.map"). Review: http://llvm-reviews.chandlerc.com/D1637 llvm-svn: 190497
2013-09-11 15:20:44 +08:00
}
if (const FileEntry *File = SourceMgr.getFileManager().getFile(FileNameRef))
Reinstate r223753, reverted in r223759 due to breakage of clang-tools-extra. Original commit message: [modules] Add experimental -fmodule-map-file-home-is-cwd flag to -cc1. For files named by -fmodule-map-file=, and files found by 'extern module' directives, this flag specifies that we should resolve filenames relative to the current working directory rather than relative to the directory in which the module map file resides. This is aimed at fixing path handling, in particular for relative -I paths, when building modules that represent components of the current project (rather than libraries installed on the current system, which the current project has as dependencies, where we'd typically expect the module map files to be looked up implicitly). llvm-svn: 223913
2014-12-10 11:09:48 +08:00
Map.parseModuleMapFile(
File, /*IsSystem=*/false,
Map.HeaderInfo.getHeaderSearchOpts().ModuleMapFileHomeIsCwd
? Directory
[modules] When diagnosing errors in module map files found by 'extern module' declarations, show how we got to that module map file. llvm-svn: 242105
2015-07-14 10:06:01 +08:00
: File->getDir(), ExternLoc);
Support for modular module-map-files This patch is the first step to make module-map-files modular (instead of requiring a single "module.map"-file per include directory). This step adds a new "extern module" declaration that enables module-map-files to reference one another along with a very basic implementation. The next steps are: * Combine this with the use-declaration (from http://llvm-reviews.chandlerc.com/D1546) in order to only load module map files required for a specific compilation. * Add an additional flag to start with a specific module-map-file (instead of requiring there to be at least one "module.map"). Review: http://llvm-reviews.chandlerc.com/D1637 llvm-svn: 190497
2013-09-11 15:20:44 +08:00
}
[Modules] Add Darwin-specific compatibility module map parsing hacks 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. llvm-svn: 244912
2015-08-14 01:13:33 +08:00
/// Whether to add the requirement \p Feature to the module \p M.
///
/// 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. We
/// drop the 'excluded' requirement, and set \p IsRequiresExcludedHack to
/// true. Later, this bit will be used to map all the headers inside this
/// module to 'textual'.
///
/// This affects Darwin.C.excluded (for assert.h) and Tcl.Private.
///
/// 2. Removes a bogus cplusplus requirement from IOKit.avc. This requirement
/// was never correct and causes issues now that we check it, so drop it.
static bool shouldAddRequirement(Module *M, StringRef Feature,
bool &IsRequiresExcludedHack) {
[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
2016-11-16 02:56:39 +08:00
if (Feature == "excluded" &&
(M->fullModuleNameIs({"Darwin", "C", "excluded"}) ||
M->fullModuleNameIs({"Tcl", "Private"}))) {
[Modules] Add Darwin-specific compatibility module map parsing hacks 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. llvm-svn: 244912
2015-08-14 01:13:33 +08:00
IsRequiresExcludedHack = true;
return false;
[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
2016-11-16 02:56:39 +08:00
} else if (Feature == "cplusplus" && M->fullModuleNameIs({"IOKit", "avc"})) {
[Modules] Add Darwin-specific compatibility module map parsing hacks 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. llvm-svn: 244912
2015-08-14 01:13:33 +08:00
return false;
}
return true;
}
Implement support for module requirements, which indicate the language features needed for a particular module to be available. This allows mixed-language modules, where certain headers only work under some language variants (e.g., in C++, std.tuple might only be available in C++11 mode). llvm-svn: 147387
2011-12-31 12:05:44 +08:00
/// \brief Parse a requires declaration.
///
/// requires-declaration:
/// 'requires' feature-list
///
/// feature-list:
Allow a new syntax in a module requires-declaration: requires ! feature The purpose of this is to allow (for instance) the module map for /usr/include to exclude <tgmath.h> and <complex.h> when building in C++ (these headers are instead provided by the C++ standard library in this case, and the glibc C <tgmath.h> header would otherwise try to include <complex.h>, resulting in a module cycle). llvm-svn: 193549
2013-10-29 06:18:19 +08:00
/// feature ',' feature-list
/// feature
///
/// feature:
/// '!'[opt] identifier
Implement support for module requirements, which indicate the language features needed for a particular module to be available. This allows mixed-language modules, where certain headers only work under some language variants (e.g., in C++, std.tuple might only be available in C++11 mode). llvm-svn: 147387
2011-12-31 12:05:44 +08:00
void ModuleMapParser::parseRequiresDecl() {
assert(Tok.is(MMToken::RequiresKeyword));
// Parse 'requires' keyword.
consumeToken();
// Parse the feature-list.
do {
Allow a new syntax in a module requires-declaration: requires ! feature The purpose of this is to allow (for instance) the module map for /usr/include to exclude <tgmath.h> and <complex.h> when building in C++ (these headers are instead provided by the C++ standard library in this case, and the glibc C <tgmath.h> header would otherwise try to include <complex.h>, resulting in a module cycle). llvm-svn: 193549
2013-10-29 06:18:19 +08:00
bool RequiredState = true;
if (Tok.is(MMToken::Exclaim)) {
RequiredState = false;
consumeToken();
}
Implement support for module requirements, which indicate the language features needed for a particular module to be available. This allows mixed-language modules, where certain headers only work under some language variants (e.g., in C++, std.tuple might only be available in C++11 mode). llvm-svn: 147387
2011-12-31 12:05:44 +08:00
if (!Tok.is(MMToken::Identifier)) {
Diags.Report(Tok.getLocation(), diag::err_mmap_expected_feature);
HadError = true;
return;
}
// Consume the feature name.
std::string Feature = Tok.getString();
consumeToken();
[Modules] Add Darwin-specific compatibility module map parsing hacks 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. llvm-svn: 244912
2015-08-14 01:13:33 +08:00
bool IsRequiresExcludedHack = false;
bool ShouldAddRequirement =
shouldAddRequirement(ActiveModule, Feature, IsRequiresExcludedHack);
if (IsRequiresExcludedHack)
UsesRequiresExcludedHack.insert(ActiveModule);
if (ShouldAddRequirement) {
// Add this feature.
ActiveModule->addRequirement(Feature, RequiredState, Map.LangOpts,
*Map.Target);
}
Implement support for module requirements, which indicate the language features needed for a particular module to be available. This allows mixed-language modules, where certain headers only work under some language variants (e.g., in C++, std.tuple might only be available in C++11 mode). llvm-svn: 147387
2011-12-31 12:05:44 +08:00
if (!Tok.is(MMToken::Comma))
break;
// Consume the comma.
consumeToken();
} while (true);
}
Implement modules support for subframeworks (aka embedded frameworks). A submodule can now be labeled as a "framework", and header search will look into the appropriate Headers/PrivateHeaders subdirectories for named headers. llvm-svn: 145941
2011-12-07 01:16:41 +08:00
/// \brief Append to \p Paths the set of paths needed to get to the
/// subframework in which the given module lives.
Move instantiateTemplateAttribute into the sema namespace, make helpers static. llvm-svn: 149864
2012-02-06 19:13:08 +08:00
static void appendSubframeworkPaths(Module *Mod,
Remove useless 'llvm::' qualifier from names like StringRef and others that are brought into 'clang' namespace by clang/Basic/LLVM.h llvm-svn: 172323
2013-01-13 03:30:44 +08:00
SmallVectorImpl<char> &Path) {
Implement modules support for subframeworks (aka embedded frameworks). A submodule can now be labeled as a "framework", and header search will look into the appropriate Headers/PrivateHeaders subdirectories for named headers. llvm-svn: 145941
2011-12-07 01:16:41 +08:00
// Collect the framework names from the given module to the top-level module.
Remove useless 'llvm::' qualifier from names like StringRef and others that are brought into 'clang' namespace by clang/Basic/LLVM.h llvm-svn: 172323
2013-01-13 03:30:44 +08:00
SmallVector<StringRef, 2> Paths;
Implement modules support for subframeworks (aka embedded frameworks). A submodule can now be labeled as a "framework", and header search will look into the appropriate Headers/PrivateHeaders subdirectories for named headers. llvm-svn: 145941
2011-12-07 01:16:41 +08:00
for (; Mod; Mod = Mod->Parent) {
if (Mod->IsFramework)
Paths.push_back(Mod->Name);
}
if (Paths.empty())
return;
// Add Frameworks/Name.framework for each subframework.
Use the multiple argument form of path::append. llvm-svn: 185164
2013-06-29 00:25:46 +08:00
for (unsigned I = Paths.size() - 1; I != 0; --I)
llvm::sys::path::append(Path, "Frameworks", Paths[I-1] + ".framework");
Implement modules support for subframeworks (aka embedded frameworks). A submodule can now be labeled as a "framework", and header search will look into the appropriate Headers/PrivateHeaders subdirectories for named headers. llvm-svn: 145941
2011-12-07 01:16:41 +08:00
}
Tweak the syntax of umbrella headers, so that "umbrella" is treated as a modifier for a header declarartion, e.g., umbrella header "headername" Collapse the umbrella-handling code in the parser into the header-handling code, so we don't duplicate the header-search logic. llvm-svn: 146159
2011-12-09 02:00:48 +08:00
/// \brief Parse a header declaration.
Introduce basic support for parsing module map files. Module map files provide a way to map between headers and modules, so that we can layer a module system on top of existing headers without changing those headers at all. This commit introduces the module map file parser and the module map that it generates, and wires up the module map file parser so that we'll automatically find module map files as part of header search. Note that we don't yet use the information stored in the module map. llvm-svn: 144402
2011-11-12 03:10:28 +08:00
///
Tweak the syntax of umbrella headers, so that "umbrella" is treated as a modifier for a header declarartion, e.g., umbrella header "headername" Collapse the umbrella-handling code in the parser into the header-handling code, so we don't duplicate the header-search logic. llvm-svn: 146159
2011-12-09 02:00:48 +08:00
/// header-declaration:
[modules] Add support for 'textual header' directives. This allows a module to specify that it logically contains a file, but that said file is non-modular and intended for textual inclusion. This allows layering checks to work properly in the presence of such files. llvm-svn: 220448
2014-10-23 07:50:56 +08:00
/// 'textual'[opt] 'header' string-literal
[modules] Support combining 'textual' with 'private'. llvm-svn: 220589
2014-10-25 04:23:01 +08:00
/// 'private' 'textual'[opt] 'header' string-literal
/// 'exclude' 'header' string-literal
/// 'umbrella' 'header' string-literal
[modules] Add support for 'textual header' directives. This allows a module to specify that it logically contains a file, but that said file is non-modular and intended for textual inclusion. This allows layering checks to work properly in the presence of such files. llvm-svn: 220448
2014-10-23 07:50:56 +08:00
///
/// FIXME: Support 'private textual header'.
This patch adds new private headers to the module map. Private headers may be included from within the module, but not from outside the module. llvm-svn: 184471
2013-06-21 05:14:14 +08:00
void ModuleMapParser::parseHeaderDecl(MMToken::TokenKind LeadingToken,
SourceLocation LeadingLoc) {
[modules] Support combining 'textual' with 'private'. llvm-svn: 220589
2014-10-25 04:23:01 +08:00
// We've already consumed the first token.
ModuleMap::ModuleHeaderRole Role = ModuleMap::NormalHeader;
if (LeadingToken == MMToken::PrivateKeyword) {
Role = ModuleMap::PrivateHeader;
// 'private' may optionally be followed by 'textual'.
if (Tok.is(MMToken::TextualKeyword)) {
LeadingToken = Tok.Kind;
consumeToken();
}
}
[Modules] Add Darwin-specific compatibility module map parsing hacks 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. llvm-svn: 244912
2015-08-14 01:13:33 +08:00
[modules] Support combining 'textual' with 'private'. llvm-svn: 220589
2014-10-25 04:23:01 +08:00
if (LeadingToken == MMToken::TextualKeyword)
Role = ModuleMap::ModuleHeaderRole(Role | ModuleMap::TextualHeader);
[Modules] Add Darwin-specific compatibility module map parsing hacks 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. llvm-svn: 244912
2015-08-14 01:13:33 +08:00
if (UsesRequiresExcludedHack.count(ActiveModule)) {
// Mark this header 'textual' (see doc comment for
// Module::UsesRequiresExcludedHack).
Role = ModuleMap::ModuleHeaderRole(Role | ModuleMap::TextualHeader);
}
[modules] Support combining 'textual' with 'private'. llvm-svn: 220589
2014-10-25 04:23:01 +08:00
if (LeadingToken != MMToken::HeaderKeyword) {
if (!Tok.is(MMToken::HeaderKeyword)) {
Diags.Report(Tok.getLocation(), diag::err_mmap_expected_header)
<< (LeadingToken == MMToken::PrivateKeyword ? "private" :
LeadingToken == MMToken::ExcludeKeyword ? "exclude" :
LeadingToken == MMToken::TextualKeyword ? "textual" : "umbrella");
return;
}
consumeToken();
}
Tweak the syntax of umbrella headers, so that "umbrella" is treated as a modifier for a header declarartion, e.g., umbrella header "headername" Collapse the umbrella-handling code in the parser into the header-handling code, so we don't duplicate the header-search logic. llvm-svn: 146159
2011-12-09 02:00:48 +08:00
Introduce basic support for parsing module map files. Module map files provide a way to map between headers and modules, so that we can layer a module system on top of existing headers without changing those headers at all. This commit introduces the module map file parser and the module map that it generates, and wires up the module map file parser so that we'll automatically find module map files as part of header search. Note that we don't yet use the information stored in the module map. llvm-svn: 144402
2011-11-12 03:10:28 +08:00
// Parse the header name.
if (!Tok.is(MMToken::StringLiteral)) {
Diags.Report(Tok.getLocation(), diag::err_mmap_expected_header)
Tweak the syntax of umbrella headers, so that "umbrella" is treated as a modifier for a header declarartion, e.g., umbrella header "headername" Collapse the umbrella-handling code in the parser into the header-handling code, so we don't duplicate the header-search logic. llvm-svn: 146159
2011-12-09 02:00:48 +08:00
<< "header";
Introduce basic support for parsing module map files. Module map files provide a way to map between headers and modules, so that we can layer a module system on top of existing headers without changing those headers at all. This commit introduces the module map file parser and the module map that it generates, and wires up the module map file parser so that we'll automatically find module map files as part of header search. Note that we don't yet use the information stored in the module map. llvm-svn: 144402
2011-11-12 03:10:28 +08:00
HadError = true;
return;
}
[modules] Track how 'header' directives were written in module map files, rather than trying to extract this information from the FileEntry after the fact. This has a number of beneficial effects. For instance, diagnostic messages for failed module builds give a path relative to the "module root" rather than an absolute file path, and the contents of the module includes file is no longer dependent on what files the including TU happened to inspect prior to triggering the module build. llvm-svn: 223095
2014-12-02 08:08:08 +08:00
Module::UnresolvedHeaderDirective Header;
Modules: Don't warn upon missing headers while reading the module map. Instead, mark the module as unavailable so that clang errors as soon as someone tries to build this module. This works towards the long-term goal of not stat'ing the header files at all while reading the module map and instead read them only when the module is being built (there is a corresponding FIXME in parseHeaderDecl()). However, it seems non-trivial to get there and this unblock us and moves us into the right direction. Also changed the implementation to reuse the same DiagnosticsEngine. llvm-svn: 197485
2013-12-17 18:31:37 +08:00
Header.FileName = Tok.getString();
Header.FileNameLoc = consumeToken();
Tweak the syntax of umbrella headers, so that "umbrella" is treated as a modifier for a header declarartion, e.g., umbrella header "headername" Collapse the umbrella-handling code in the parser into the header-handling code, so we don't duplicate the header-search logic. llvm-svn: 146159
2011-12-09 02:00:48 +08:00
Implement umbrella directories for modules, which are similar to umbrella headers in the sense that all of the headers within that directory (and eventually its subdirectories) are considered to be part of the module with that umbrella directory. However, unlike umbrella headers, which are expected to include all of the headers within their subdirectories, Clang will automatically include all of the headers it finds in the named subdirectory. The intent here is to allow a module map to trivially turn a subdirectory into a module, where the module's structure can mimic the directory structure. llvm-svn: 146165
2011-12-09 03:11:24 +08:00
// Check whether we already have an umbrella.
This patch adds new private headers to the module map. Private headers may be included from within the module, but not from outside the module. llvm-svn: 184471
2013-06-21 05:14:14 +08:00
if (LeadingToken == MMToken::UmbrellaKeyword && ActiveModule->Umbrella) {
Modules: Don't warn upon missing headers while reading the module map. Instead, mark the module as unavailable so that clang errors as soon as someone tries to build this module. This works towards the long-term goal of not stat'ing the header files at all while reading the module map and instead read them only when the module is being built (there is a corresponding FIXME in parseHeaderDecl()). However, it seems non-trivial to get there and this unblock us and moves us into the right direction. Also changed the implementation to reuse the same DiagnosticsEngine. llvm-svn: 197485
2013-12-17 18:31:37 +08:00
Diags.Report(Header.FileNameLoc, diag::err_mmap_umbrella_clash)
Implement umbrella directories for modules, which are similar to umbrella headers in the sense that all of the headers within that directory (and eventually its subdirectories) are considered to be part of the module with that umbrella directory. However, unlike umbrella headers, which are expected to include all of the headers within their subdirectories, Clang will automatically include all of the headers it finds in the named subdirectory. The intent here is to allow a module map to trivially turn a subdirectory into a module, where the module's structure can mimic the directory structure. llvm-svn: 146165
2011-12-09 03:11:24 +08:00
<< ActiveModule->getFullModuleName();
Resolve the header files named in module map "header" and "umbrella" declarations to actual files. llvm-svn: 144408
2011-11-12 05:55:48 +08:00
HadError = true;
return;
}
Add the notion of "framework" modules to module maps. Framework modules (obviously) describe frameworks, and understand the header layout of frameworks. llvm-svn: 144921
2011-11-18 06:09:43 +08:00
Resolve the header files named in module map "header" and "umbrella" declarations to actual files. llvm-svn: 144408
2011-11-12 05:55:48 +08:00
// Look for this file.
[C++11] Use 'nullptr'. Lex edition. llvm-svn: 209083
2014-05-18 07:10:59 +08:00
const FileEntry *File = nullptr;
const FileEntry *BuiltinFile = nullptr;
[modules] Track how 'header' directives were written in module map files, rather than trying to extract this information from the FileEntry after the fact. This has a number of beneficial effects. For instance, diagnostic messages for failed module builds give a path relative to the "module root" rather than an absolute file path, and the contents of the module includes file is no longer dependent on what files the including TU happened to inspect prior to triggering the module build. llvm-svn: 223095
2014-12-02 08:08:08 +08:00
SmallString<128> RelativePathName;
Modules: Don't warn upon missing headers while reading the module map. Instead, mark the module as unavailable so that clang errors as soon as someone tries to build this module. This works towards the long-term goal of not stat'ing the header files at all while reading the module map and instead read them only when the module is being built (there is a corresponding FIXME in parseHeaderDecl()). However, it seems non-trivial to get there and this unblock us and moves us into the right direction. Also changed the implementation to reuse the same DiagnosticsEngine. llvm-svn: 197485
2013-12-17 18:31:37 +08:00
if (llvm::sys::path::is_absolute(Header.FileName)) {
[modules] Track how 'header' directives were written in module map files, rather than trying to extract this information from the FileEntry after the fact. This has a number of beneficial effects. For instance, diagnostic messages for failed module builds give a path relative to the "module root" rather than an absolute file path, and the contents of the module includes file is no longer dependent on what files the including TU happened to inspect prior to triggering the module build. llvm-svn: 223095
2014-12-02 08:08:08 +08:00
RelativePathName = Header.FileName;
File = SourceMgr.getFileManager().getFile(RelativePathName);
Implement basic support for private headers in frameworks. In essence, when we load a module map (module.map) from a directory, also load a private module map (module_private.map) for that directory, if present. That private module map can inject a new submodule that captures private headers. llvm-svn: 146012
2011-12-07 10:23:45 +08:00
} else {
// Search for the header file within the search directory.
[modules] Track how 'header' directives were written in module map files, rather than trying to extract this information from the FileEntry after the fact. This has a number of beneficial effects. For instance, diagnostic messages for failed module builds give a path relative to the "module root" rather than an absolute file path, and the contents of the module includes file is no longer dependent on what files the including TU happened to inspect prior to triggering the module build. llvm-svn: 223095
2014-12-02 08:08:08 +08:00
SmallString<128> FullPathName(Directory->getName());
unsigned FullPathLength = FullPathName.size();
Switch on-demand module building over to use module maps, always. When we infer the module map, we'll just print the module map to a temporary file and generate the module using that. llvm-svn: 145436
2011-11-30 05:59:16 +08:00
Implement modules support for subframeworks (aka embedded frameworks). A submodule can now be labeled as a "framework", and header search will look into the appropriate Headers/PrivateHeaders subdirectories for named headers. llvm-svn: 145941
2011-12-07 01:16:41 +08:00
if (ActiveModule->isPartOfFramework()) {
[modules] Track how 'header' directives were written in module map files, rather than trying to extract this information from the FileEntry after the fact. This has a number of beneficial effects. For instance, diagnostic messages for failed module builds give a path relative to the "module root" rather than an absolute file path, and the contents of the module includes file is no longer dependent on what files the including TU happened to inspect prior to triggering the module build. llvm-svn: 223095
2014-12-02 08:08:08 +08:00
appendSubframeworkPaths(ActiveModule, RelativePathName);
Implement basic support for private headers in frameworks. In essence, when we load a module map (module.map) from a directory, also load a private module map (module_private.map) for that directory, if present. That private module map can inject a new submodule that captures private headers. llvm-svn: 146012
2011-12-07 10:23:45 +08:00
// Check whether this file is in the public headers.
[modules] Track how 'header' directives were written in module map files, rather than trying to extract this information from the FileEntry after the fact. This has a number of beneficial effects. For instance, diagnostic messages for failed module builds give a path relative to the "module root" rather than an absolute file path, and the contents of the module includes file is no longer dependent on what files the including TU happened to inspect prior to triggering the module build. llvm-svn: 223095
2014-12-02 08:08:08 +08:00
llvm::sys::path::append(RelativePathName, "Headers", Header.FileName);
Remove many superfluous SmallString::str() calls. 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. llvm-svn: 232622
2015-03-18 18:17:07 +08:00
llvm::sys::path::append(FullPathName, RelativePathName);
[modules] Track how 'header' directives were written in module map files, rather than trying to extract this information from the FileEntry after the fact. This has a number of beneficial effects. For instance, diagnostic messages for failed module builds give a path relative to the "module root" rather than an absolute file path, and the contents of the module includes file is no longer dependent on what files the including TU happened to inspect prior to triggering the module build. llvm-svn: 223095
2014-12-02 08:08:08 +08:00
File = SourceMgr.getFileManager().getFile(FullPathName);
Implement basic support for private headers in frameworks. In essence, when we load a module map (module.map) from a directory, also load a private module map (module_private.map) for that directory, if present. That private module map can inject a new submodule that captures private headers. llvm-svn: 146012
2011-12-07 10:23:45 +08:00
if (!File) {
// Check whether this file is in the private headers.
[modules] Track how 'header' directives were written in module map files, rather than trying to extract this information from the FileEntry after the fact. This has a number of beneficial effects. For instance, diagnostic messages for failed module builds give a path relative to the "module root" rather than an absolute file path, and the contents of the module includes file is no longer dependent on what files the including TU happened to inspect prior to triggering the module build. llvm-svn: 223095
2014-12-02 08:08:08 +08:00
// FIXME: Should we retain the subframework paths here?
RelativePathName.clear();
FullPathName.resize(FullPathLength);
llvm::sys::path::append(RelativePathName, "PrivateHeaders",
Header.FileName);
Remove many superfluous SmallString::str() calls. 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. llvm-svn: 232622
2015-03-18 18:17:07 +08:00
llvm::sys::path::append(FullPathName, RelativePathName);
[modules] Track how 'header' directives were written in module map files, rather than trying to extract this information from the FileEntry after the fact. This has a number of beneficial effects. For instance, diagnostic messages for failed module builds give a path relative to the "module root" rather than an absolute file path, and the contents of the module includes file is no longer dependent on what files the including TU happened to inspect prior to triggering the module build. llvm-svn: 223095
2014-12-02 08:08:08 +08:00
File = SourceMgr.getFileManager().getFile(FullPathName);
Implement basic support for private headers in frameworks. In essence, when we load a module map (module.map) from a directory, also load a private module map (module_private.map) for that directory, if present. That private module map can inject a new submodule that captures private headers. llvm-svn: 146012
2011-12-07 10:23:45 +08:00
}
} else {
// Lookup for normal headers.
[modules] Track how 'header' directives were written in module map files, rather than trying to extract this information from the FileEntry after the fact. This has a number of beneficial effects. For instance, diagnostic messages for failed module builds give a path relative to the "module root" rather than an absolute file path, and the contents of the module includes file is no longer dependent on what files the including TU happened to inspect prior to triggering the module build. llvm-svn: 223095
2014-12-02 08:08:08 +08:00
llvm::sys::path::append(RelativePathName, Header.FileName);
Remove many superfluous SmallString::str() calls. 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. llvm-svn: 232622
2015-03-18 18:17:07 +08:00
llvm::sys::path::append(FullPathName, RelativePathName);
[modules] Track how 'header' directives were written in module map files, rather than trying to extract this information from the FileEntry after the fact. This has a number of beneficial effects. For instance, diagnostic messages for failed module builds give a path relative to the "module root" rather than an absolute file path, and the contents of the module includes file is no longer dependent on what files the including TU happened to inspect prior to triggering the module build. llvm-svn: 223095
2014-12-02 08:08:08 +08:00
File = SourceMgr.getFileManager().getFile(FullPathName);
Back out my heinous hack that tricked the module generation mechanism into using non-absolute system includes (<foo>)... ... and introduce another hack that is simultaneously more heineous and more effective. We whitelist Clang-supplied headers that augment or override system headers (such as float.h, stdarg.h, and tgmath.h). For these headers, Clang does not provide a module mapping. Instead, a system-supplied module map can refer to these headers in a system module, and Clang will look both in its own include directory and wherever the system-supplied module map suggests, then adds either or both headers. The end result is that Clang-supplied headers get merged into the system-supplied module for the C standard library. As a drive-by, fix up a few dependencies in the _Builtin_instrinsics module. llvm-svn: 149611
2012-02-03 02:42:48 +08:00
// If this is a system module with a top-level header, this header
// may have a counterpart (or replacement) in the set of headers
// supplied by Clang. Find that builtin header.
This patch adds new private headers to the module map. Private headers may be included from within the module, but not from outside the module. llvm-svn: 184471
2013-06-21 05:14:14 +08:00
if (ActiveModule->IsSystem && LeadingToken != MMToken::UmbrellaKeyword &&
BuiltinIncludeDir && BuiltinIncludeDir != Directory &&
Modules: Don't warn upon missing headers while reading the module map. Instead, mark the module as unavailable so that clang errors as soon as someone tries to build this module. This works towards the long-term goal of not stat'ing the header files at all while reading the module map and instead read them only when the module is being built (there is a corresponding FIXME in parseHeaderDecl()). However, it seems non-trivial to get there and this unblock us and moves us into the right direction. Also changed the implementation to reuse the same DiagnosticsEngine. llvm-svn: 197485
2013-12-17 18:31:37 +08:00
isBuiltinHeader(Header.FileName)) {
Basic: import SmallString<> into clang namespace (I was going to fix the TODO about DenseMap too, but that would break self-host right now. See PR11922.) llvm-svn: 149799
2012-02-05 10:13:05 +08:00
SmallString<128> BuiltinPathName(BuiltinIncludeDir->getName());
Modules: Don't warn upon missing headers while reading the module map. Instead, mark the module as unavailable so that clang errors as soon as someone tries to build this module. This works towards the long-term goal of not stat'ing the header files at all while reading the module map and instead read them only when the module is being built (there is a corresponding FIXME in parseHeaderDecl()). However, it seems non-trivial to get there and this unblock us and moves us into the right direction. Also changed the implementation to reuse the same DiagnosticsEngine. llvm-svn: 197485
2013-12-17 18:31:37 +08:00
llvm::sys::path::append(BuiltinPathName, Header.FileName);
Back out my heinous hack that tricked the module generation mechanism into using non-absolute system includes (<foo>)... ... and introduce another hack that is simultaneously more heineous and more effective. We whitelist Clang-supplied headers that augment or override system headers (such as float.h, stdarg.h, and tgmath.h). For these headers, Clang does not provide a module mapping. Instead, a system-supplied module map can refer to these headers in a system module, and Clang will look both in its own include directory and wherever the system-supplied module map suggests, then adds either or both headers. The end result is that Clang-supplied headers get merged into the system-supplied module for the C standard library. As a drive-by, fix up a few dependencies in the _Builtin_instrinsics module. llvm-svn: 149611
2012-02-03 02:42:48 +08:00
BuiltinFile = SourceMgr.getFileManager().getFile(BuiltinPathName);
[modules] Track how 'header' directives were written in module map files, rather than trying to extract this information from the FileEntry after the fact. This has a number of beneficial effects. For instance, diagnostic messages for failed module builds give a path relative to the "module root" rather than an absolute file path, and the contents of the module includes file is no longer dependent on what files the including TU happened to inspect prior to triggering the module build. llvm-svn: 223095
2014-12-02 08:08:08 +08:00
Back out my heinous hack that tricked the module generation mechanism into using non-absolute system includes (<foo>)... ... and introduce another hack that is simultaneously more heineous and more effective. We whitelist Clang-supplied headers that augment or override system headers (such as float.h, stdarg.h, and tgmath.h). For these headers, Clang does not provide a module mapping. Instead, a system-supplied module map can refer to these headers in a system module, and Clang will look both in its own include directory and wherever the system-supplied module map suggests, then adds either or both headers. The end result is that Clang-supplied headers get merged into the system-supplied module for the C standard library. As a drive-by, fix up a few dependencies in the _Builtin_instrinsics module. llvm-svn: 149611
2012-02-03 02:42:48 +08:00
// If Clang supplies this header but the underlying system does not,
// just silently swap in our builtin version. Otherwise, we'll end
// up adding both (later).
[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
2016-10-21 09:41:56 +08:00
if (BuiltinFile && !File) {
Back out my heinous hack that tricked the module generation mechanism into using non-absolute system includes (<foo>)... ... and introduce another hack that is simultaneously more heineous and more effective. We whitelist Clang-supplied headers that augment or override system headers (such as float.h, stdarg.h, and tgmath.h). For these headers, Clang does not provide a module mapping. Instead, a system-supplied module map can refer to these headers in a system module, and Clang will look both in its own include directory and wherever the system-supplied module map suggests, then adds either or both headers. The end result is that Clang-supplied headers get merged into the system-supplied module for the C standard library. As a drive-by, fix up a few dependencies in the _Builtin_instrinsics module. llvm-svn: 149611
2012-02-03 02:42:48 +08:00
File = BuiltinFile;
[modules] Track how 'header' directives were written in module map files, rather than trying to extract this information from the FileEntry after the fact. This has a number of beneficial effects. For instance, diagnostic messages for failed module builds give a path relative to the "module root" rather than an absolute file path, and the contents of the module includes file is no longer dependent on what files the including TU happened to inspect prior to triggering the module build. llvm-svn: 223095
2014-12-02 08:08:08 +08:00
RelativePathName = BuiltinPathName;
[C++11] Use 'nullptr'. Lex edition. llvm-svn: 209083
2014-05-18 07:10:59 +08:00
BuiltinFile = nullptr;
Back out my heinous hack that tricked the module generation mechanism into using non-absolute system includes (<foo>)... ... and introduce another hack that is simultaneously more heineous and more effective. We whitelist Clang-supplied headers that augment or override system headers (such as float.h, stdarg.h, and tgmath.h). For these headers, Clang does not provide a module mapping. Instead, a system-supplied module map can refer to these headers in a system module, and Clang will look both in its own include directory and wherever the system-supplied module map suggests, then adds either or both headers. The end result is that Clang-supplied headers get merged into the system-supplied module for the C standard library. As a drive-by, fix up a few dependencies in the _Builtin_instrinsics module. llvm-svn: 149611
2012-02-03 02:42:48 +08:00
}
}
Implement modules support for subframeworks (aka embedded frameworks). A submodule can now be labeled as a "framework", and header search will look into the appropriate Headers/PrivateHeaders subdirectories for named headers. llvm-svn: 145941
2011-12-07 01:16:41 +08:00
}
Switch on-demand module building over to use module maps, always. When we infer the module map, we'll just print the module map to a temporary file and generate the module using that. llvm-svn: 145436
2011-11-30 05:59:16 +08:00
}
[modules] Track how 'header' directives were written in module map files, rather than trying to extract this information from the FileEntry after the fact. This has a number of beneficial effects. For instance, diagnostic messages for failed module builds give a path relative to the "module root" rather than an absolute file path, and the contents of the module includes file is no longer dependent on what files the including TU happened to inspect prior to triggering the module build. llvm-svn: 223095
2014-12-02 08:08:08 +08:00
Resolve the header files named in module map "header" and "umbrella" declarations to actual files. llvm-svn: 144408
2011-11-12 05:55:48 +08:00
// FIXME: We shouldn't be eagerly stat'ing every file named in a module map.
// Come up with a lazy way to do this.
Implement basic support for private headers in frameworks. In essence, when we load a module map (module.map) from a directory, also load a private module map (module_private.map) for that directory, if present. That private module map can inject a new submodule that captures private headers. llvm-svn: 146012
2011-12-07 10:23:45 +08:00
if (File) {
Allow a header to be part of multiple modules. This patch changes two things: a) Allow a header to be part of multiple modules. The reasoning is that in existing codebases that have a module-like build system, the same headers might be used in several build targets. Simple reasons might be that they defined different classes that are declared in the same header. Supporting a header as a part of multiple modules will make the transistion easier for those cases. A later step in clang can then determine whether the two modules are actually compatible and can be merged and error out appropriately. The later check is similar to what needs to be done for template specializations anyway. b) Allow modules to be stored in a directory tree separate from the headers they describe. Review: http://llvm-reviews.chandlerc.com/D1951 llvm-svn: 193151
2013-10-22 16:09:47 +08:00
if (LeadingToken == MMToken::UmbrellaKeyword) {
Tweak the syntax of umbrella headers, so that "umbrella" is treated as a modifier for a header declarartion, e.g., umbrella header "headername" Collapse the umbrella-handling code in the parser into the header-handling code, so we don't duplicate the header-search logic. llvm-svn: 146159
2011-12-09 02:00:48 +08:00
const DirectoryEntry *UmbrellaDir = File->getDir();
Introduce the notion of excluded headers into the module map description. Previously, one could emulate this behavior by placing the header in an always-unavailable submodule, but Argyrios guilted me into expressing this idea properly. llvm-svn: 165921
2012-10-15 14:28:11 +08:00
if (Module *UmbrellaModule = Map.UmbrellaDirs[UmbrellaDir]) {
This patch adds new private headers to the module map. Private headers may be included from within the module, but not from outside the module. llvm-svn: 184471
2013-06-21 05:14:14 +08:00
Diags.Report(LeadingLoc, diag::err_mmap_umbrella_clash)
Introduce the notion of excluded headers into the module map description. Previously, one could emulate this behavior by placing the header in an always-unavailable submodule, but Argyrios guilted me into expressing this idea properly. llvm-svn: 165921
2012-10-15 14:28:11 +08:00
<< UmbrellaModule->getFullModuleName();
Tweak the syntax of umbrella headers, so that "umbrella" is treated as a modifier for a header declarartion, e.g., umbrella header "headername" Collapse the umbrella-handling code in the parser into the header-handling code, so we don't duplicate the header-search logic. llvm-svn: 146159
2011-12-09 02:00:48 +08:00
HadError = true;
} else {
// Record this umbrella header.
[modules] Retain the name as written for umbrella headers and directories, rather than converting to an absolute path. No observable change expected, but this allows us to correctly compute the module for an umbrella header, which later changes will require. llvm-svn: 237508
2015-05-16 10:28:53 +08:00
Map.setUmbrellaHeader(ActiveModule, File, RelativePathName.str());
Tweak the syntax of umbrella headers, so that "umbrella" is treated as a modifier for a header declarartion, e.g., umbrella header "headername" Collapse the umbrella-handling code in the parser into the header-handling code, so we don't duplicate the header-search logic. llvm-svn: 146159
2011-12-09 02:00:48 +08:00
}
Refactor implementation of 'exclude header'. This was not a real header role, and was never exposed to clients of ModuleMap. Remove the enumeration value for it and track it as marking the header as 'known' rather than creating an extra KnownHeader entry that *every single* client ignores. llvm-svn: 220460
2014-10-23 10:01:19 +08:00
} else if (LeadingToken == MMToken::ExcludeKeyword) {
Try to fix the MSVC build. llvm-svn: 223105
2014-12-02 10:13:09 +08:00
Module::Header H = {RelativePathName.str(), File};
Map.excludeHeader(ActiveModule, H);
Resolve the header files named in module map "header" and "umbrella" declarations to actual files. llvm-svn: 144408
2011-11-12 05:55:48 +08:00
} else {
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
2016-10-26 09:08:55 +08:00
// If there is a builtin counterpart to this file, add it now so it can
// wrap the system header.
Try to fix the MSVC build. llvm-svn: 223105
2014-12-02 10:13:09 +08:00
if (BuiltinFile) {
[modules] Track how 'header' directives were written in module map files, rather than trying to extract this information from the FileEntry after the fact. This has a number of beneficial effects. For instance, diagnostic messages for failed module builds give a path relative to the "module root" rather than an absolute file path, and the contents of the module includes file is no longer dependent on what files the including TU happened to inspect prior to triggering the module build. llvm-svn: 223095
2014-12-02 08:08:08 +08:00
// FIXME: Taking the name from the FileEntry is unstable and can give
// different results depending on how we've previously named that file
// in this build.
Try to fix the MSVC build. llvm-svn: 223105
2014-12-02 10:13:09 +08:00
Module::Header H = { BuiltinFile->getName(), BuiltinFile };
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
2016-10-26 09:08:55 +08:00
Map.addHeader(ActiveModule, H, Role);
// If we have both a builtin and system version of the file, the
// builtin version may want to inject macros into the system header, so
// force the system header to be treated as a textual header in this
// case.
Role = ModuleMap::ModuleHeaderRole(Role | ModuleMap::TextualHeader);
Try to fix the MSVC build. llvm-svn: 223105
2014-12-02 10:13:09 +08:00
}
[modules] Add support for #include_next. #include_next interacts poorly with modules: it depends on where in the list of include paths the current file was found. Files covered by module maps are not found in include search paths when building the module (and are not found in include search paths when @importing the module either), so this isn't really meaningful. Instead, we fake up the result that #include_next *should* have given: find the first path that would have resulted in the given file being picked, and search from there onwards. llvm-svn: 220177
2014-10-20 08:15:49 +08:00
[modules] Support combining 'textual' with 'private'. llvm-svn: 220589
2014-10-25 04:23:01 +08:00
// Record this header.
Try to fix the MSVC build. llvm-svn: 223105
2014-12-02 10:13:09 +08:00
Module::Header H = { RelativePathName.str(), File };
Map.addHeader(ActiveModule, H, Role);
Resolve the header files named in module map "header" and "umbrella" declarations to actual files. llvm-svn: 144408
2011-11-12 05:55:48 +08:00
}
This patch adds new private headers to the module map. Private headers may be included from within the module, but not from outside the module. llvm-svn: 184471
2013-06-21 05:14:14 +08:00
} else if (LeadingToken != MMToken::ExcludeKeyword) {
If an excluded header does not exist, just ignore it llvm-svn: 168077
2012-11-16 03:47:16 +08:00
// Ignore excluded header files. They're optional anyway.
Modules: Don't warn upon missing headers while reading the module map. Instead, mark the module as unavailable so that clang errors as soon as someone tries to build this module. This works towards the long-term goal of not stat'ing the header files at all while reading the module map and instead read them only when the module is being built (there is a corresponding FIXME in parseHeaderDecl()). However, it seems non-trivial to get there and this unblock us and moves us into the right direction. Also changed the implementation to reuse the same DiagnosticsEngine. llvm-svn: 197485
2013-12-17 18:31:37 +08:00
// If we find a module that has a missing header, we mark this module as
// unavailable and store the header directive for displaying diagnostics.
Header.IsUmbrella = LeadingToken == MMToken::UmbrellaKeyword;
Don't build modules with (submodules with) missing headers Unless they are in submodules that aren't available anyway, due to requirements not being met. Also, mark children as unavailable when the parent is. llvm-svn: 206664
2014-04-19 06:07:31 +08:00
ActiveModule->markUnavailable();
Modules: Don't warn upon missing headers while reading the module map. Instead, mark the module as unavailable so that clang errors as soon as someone tries to build this module. This works towards the long-term goal of not stat'ing the header files at all while reading the module map and instead read them only when the module is being built (there is a corresponding FIXME in parseHeaderDecl()). However, it seems non-trivial to get there and this unblock us and moves us into the right direction. Also changed the implementation to reuse the same DiagnosticsEngine. llvm-svn: 197485
2013-12-17 18:31:37 +08:00
ActiveModule->MissingHeaders.push_back(Header);
Implement umbrella directories for modules, which are similar to umbrella headers in the sense that all of the headers within that directory (and eventually its subdirectories) are considered to be part of the module with that umbrella directory. However, unlike umbrella headers, which are expected to include all of the headers within their subdirectories, Clang will automatically include all of the headers it finds in the named subdirectory. The intent here is to allow a module map to trivially turn a subdirectory into a module, where the module's structure can mimic the directory structure. llvm-svn: 146165
2011-12-09 03:11:24 +08:00
}
}
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
2015-08-14 01:30:07 +08:00
static int compareModuleHeaders(const Module::Header *A,
const Module::Header *B) {
return A->NameAsWritten.compare(B->NameAsWritten);
}
Implement umbrella directories for modules, which are similar to umbrella headers in the sense that all of the headers within that directory (and eventually its subdirectories) are considered to be part of the module with that umbrella directory. However, unlike umbrella headers, which are expected to include all of the headers within their subdirectories, Clang will automatically include all of the headers it finds in the named subdirectory. The intent here is to allow a module map to trivially turn a subdirectory into a module, where the module's structure can mimic the directory structure. llvm-svn: 146165
2011-12-09 03:11:24 +08:00
/// \brief Parse an umbrella directory declaration.
///
/// umbrella-dir-declaration:
/// umbrella string-literal
void ModuleMapParser::parseUmbrellaDirDecl(SourceLocation UmbrellaLoc) {
// Parse the directory name.
if (!Tok.is(MMToken::StringLiteral)) {
Diags.Report(Tok.getLocation(), diag::err_mmap_expected_header)
<< "umbrella";
HadError = true;
return;
}
std::string DirName = Tok.getString();
SourceLocation DirNameLoc = consumeToken();
// Check whether we already have an umbrella.
if (ActiveModule->Umbrella) {
Diags.Report(DirNameLoc, diag::err_mmap_umbrella_clash)
<< ActiveModule->getFullModuleName();
Resolve the header files named in module map "header" and "umbrella" declarations to actual files. llvm-svn: 144408
2011-11-12 05:55:48 +08:00
HadError = true;
Implement umbrella directories for modules, which are similar to umbrella headers in the sense that all of the headers within that directory (and eventually its subdirectories) are considered to be part of the module with that umbrella directory. However, unlike umbrella headers, which are expected to include all of the headers within their subdirectories, Clang will automatically include all of the headers it finds in the named subdirectory. The intent here is to allow a module map to trivially turn a subdirectory into a module, where the module's structure can mimic the directory structure. llvm-svn: 146165
2011-12-09 03:11:24 +08:00
return;
}
// Look for this file.
[C++11] Use 'nullptr'. Lex edition. llvm-svn: 209083
2014-05-18 07:10:59 +08:00
const DirectoryEntry *Dir = nullptr;
Implement umbrella directories for modules, which are similar to umbrella headers in the sense that all of the headers within that directory (and eventually its subdirectories) are considered to be part of the module with that umbrella directory. However, unlike umbrella headers, which are expected to include all of the headers within their subdirectories, Clang will automatically include all of the headers it finds in the named subdirectory. The intent here is to allow a module map to trivially turn a subdirectory into a module, where the module's structure can mimic the directory structure. llvm-svn: 146165
2011-12-09 03:11:24 +08:00
if (llvm::sys::path::is_absolute(DirName))
Dir = SourceMgr.getFileManager().getDirectory(DirName);
else {
Basic: import SmallString<> into clang namespace (I was going to fix the TODO about DenseMap too, but that would break self-host right now. See PR11922.) llvm-svn: 149799
2012-02-05 10:13:05 +08:00
SmallString<128> PathName;
Implement umbrella directories for modules, which are similar to umbrella headers in the sense that all of the headers within that directory (and eventually its subdirectories) are considered to be part of the module with that umbrella directory. However, unlike umbrella headers, which are expected to include all of the headers within their subdirectories, Clang will automatically include all of the headers it finds in the named subdirectory. The intent here is to allow a module map to trivially turn a subdirectory into a module, where the module's structure can mimic the directory structure. llvm-svn: 146165
2011-12-09 03:11:24 +08:00
PathName = Directory->getName();
llvm::sys::path::append(PathName, DirName);
Dir = SourceMgr.getFileManager().getDirectory(PathName);
Resolve the header files named in module map "header" and "umbrella" declarations to actual files. llvm-svn: 144408
2011-11-12 05:55:48 +08:00
}
Implement umbrella directories for modules, which are similar to umbrella headers in the sense that all of the headers within that directory (and eventually its subdirectories) are considered to be part of the module with that umbrella directory. However, unlike umbrella headers, which are expected to include all of the headers within their subdirectories, Clang will automatically include all of the headers it finds in the named subdirectory. The intent here is to allow a module map to trivially turn a subdirectory into a module, where the module's structure can mimic the directory structure. llvm-svn: 146165
2011-12-09 03:11:24 +08:00
if (!Dir) {
Diags.Report(DirNameLoc, diag::err_mmap_umbrella_dir_not_found)
<< DirName;
HadError = true;
return;
}
[Modules] Add Darwin-specific compatibility module map parsing hacks 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. llvm-svn: 244912
2015-08-14 01:13:33 +08:00
if (UsesRequiresExcludedHack.count(ActiveModule)) {
// Mark this header 'textual' (see doc comment for
// ModuleMapParser::UsesRequiresExcludedHack). Although iterating over the
// directory is relatively expensive, in practice this only applies to the
// uncommonly used Tcl module on Darwin platforms.
std::error_code EC;
SmallVector<Module::Header, 6> Headers;
[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
2016-05-17 00:46:01 +08:00
vfs::FileSystem &FS = *SourceMgr.getFileManager().getVirtualFileSystem();
for (vfs::recursive_directory_iterator I(FS, Dir->getName(), EC), E;
[Modules] Add Darwin-specific compatibility module map parsing hacks 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. llvm-svn: 244912
2015-08-14 01:13:33 +08:00
I != E && !EC; I.increment(EC)) {
[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
2016-05-17 00:46:01 +08:00
if (const FileEntry *FE =
SourceMgr.getFileManager().getFile(I->getName())) {
[Modules] Add Darwin-specific compatibility module map parsing hacks 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. llvm-svn: 244912
2015-08-14 01:13:33 +08:00
[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
2016-05-17 00:46:01 +08:00
Module::Header Header = {I->getName(), FE};
[Modules] Add Darwin-specific compatibility module map parsing hacks 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. llvm-svn: 244912
2015-08-14 01:13:33 +08:00
Headers.push_back(std::move(Header));
}
}
// Sort header paths so that the pcm doesn't depend on iteration order.
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
2015-08-14 01:30:07 +08:00
llvm::array_pod_sort(Headers.begin(), Headers.end(), compareModuleHeaders);
[Modules] Add Darwin-specific compatibility module map parsing hacks 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. llvm-svn: 244912
2015-08-14 01:13:33 +08:00
for (auto &Header : Headers)
Map.addHeader(ActiveModule, std::move(Header), ModuleMap::TextualHeader);
return;
}
Implement umbrella directories for modules, which are similar to umbrella headers in the sense that all of the headers within that directory (and eventually its subdirectories) are considered to be part of the module with that umbrella directory. However, unlike umbrella headers, which are expected to include all of the headers within their subdirectories, Clang will automatically include all of the headers it finds in the named subdirectory. The intent here is to allow a module map to trivially turn a subdirectory into a module, where the module's structure can mimic the directory structure. llvm-svn: 146165
2011-12-09 03:11:24 +08:00
if (Module *OwningModule = Map.UmbrellaDirs[Dir]) {
Diags.Report(UmbrellaLoc, diag::err_mmap_umbrella_clash)
<< OwningModule->getFullModuleName();
HadError = true;
return;
[Modules] Add Darwin-specific compatibility module map parsing hacks 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. llvm-svn: 244912
2015-08-14 01:13:33 +08:00
}
Implement umbrella directories for modules, which are similar to umbrella headers in the sense that all of the headers within that directory (and eventually its subdirectories) are considered to be part of the module with that umbrella directory. However, unlike umbrella headers, which are expected to include all of the headers within their subdirectories, Clang will automatically include all of the headers it finds in the named subdirectory. The intent here is to allow a module map to trivially turn a subdirectory into a module, where the module's structure can mimic the directory structure. llvm-svn: 146165
2011-12-09 03:11:24 +08:00
// Record this umbrella directory.
[modules] Retain the name as written for umbrella headers and directories, rather than converting to an absolute path. No observable change expected, but this allows us to correctly compute the module for an umbrella header, which later changes will require. llvm-svn: 237508
2015-05-16 10:28:53 +08:00
Map.setUmbrellaDir(ActiveModule, Dir, DirName);
Introduce basic support for parsing module map files. Module map files provide a way to map between headers and modules, so that we can layer a module system on top of existing headers without changing those headers at all. This commit introduces the module map file parser and the module map that it generates, and wires up the module map file parser so that we'll automatically find module map files as part of header search. Note that we don't yet use the information stored in the module map. llvm-svn: 144402
2011-11-12 03:10:28 +08:00
}
Implementing parsing and resolution of module export declarations within module maps, which will (eventually) be used to re-export a module from another module. There are still some pieces missing, however. llvm-svn: 145665
2011-12-02 09:47:07 +08:00
/// \brief Parse a module export declaration.
///
/// export-declaration:
/// 'export' wildcard-module-id
///
/// wildcard-module-id:
/// identifier
/// '*'
/// identifier '.' wildcard-module-id
void ModuleMapParser::parseExportDecl() {
assert(Tok.is(MMToken::ExportKeyword));
SourceLocation ExportLoc = consumeToken();
// Parse the module-id with an optional wildcard at the end.
ModuleId ParsedModuleId;
bool Wildcard = false;
do {
[modules] Add support for 'textual header' directives. This allows a module to specify that it logically contains a file, but that said file is non-modular and intended for textual inclusion. This allows layering checks to work properly in the presence of such files. llvm-svn: 220448
2014-10-23 07:50:56 +08:00
// FIXME: Support string-literal module names here.
Implementing parsing and resolution of module export declarations within module maps, which will (eventually) be used to re-export a module from another module. There are still some pieces missing, however. llvm-svn: 145665
2011-12-02 09:47:07 +08:00
if (Tok.is(MMToken::Identifier)) {
ParsedModuleId.push_back(std::make_pair(Tok.getString(),
Tok.getLocation()));
consumeToken();
if (Tok.is(MMToken::Period)) {
consumeToken();
continue;
}
break;
}
if(Tok.is(MMToken::Star)) {
Wildcard = true;
Implement support for wildcard exports in modules, allowing a module to re-export anything that it imports. This opt-in feature makes a module behave more like a header, because it can be used to re-export the transitive closure of a (sub)module's dependencies. llvm-svn: 145811
2011-12-06 01:28:06 +08:00
consumeToken();
Implementing parsing and resolution of module export declarations within module maps, which will (eventually) be used to re-export a module from another module. There are still some pieces missing, however. llvm-svn: 145665
2011-12-02 09:47:07 +08:00
break;
}
Module use declarations (II) Review: http://llvm-reviews.chandlerc.com/D1546. I have picked up this patch form Lawrence (http://llvm-reviews.chandlerc.com/D1063) and did a few changes. From the original change description (updated as appropriate): This patch adds a check that ensures that modules only use modules they have so declared. To this end, it adds a statement on intended module use to the module.map grammar: use module-id A module can then only use headers from other modules if it 'uses' them. This enforcement is off by default, but may be turned on with the new option -fmodules-decluse. When enforcing the module semantics, we also need to consider a source file part of a module. This is achieved with a compiler option -fmodule-name=<module-id>. The compiler at present only applies restrictions to the module directly being built. llvm-svn: 191283
2013-09-24 17:14:14 +08:00
Diags.Report(Tok.getLocation(), diag::err_mmap_module_id);
Implementing parsing and resolution of module export declarations within module maps, which will (eventually) be used to re-export a module from another module. There are still some pieces missing, however. llvm-svn: 145665
2011-12-02 09:47:07 +08:00
HadError = true;
return;
} while (true);
Module::UnresolvedExportDecl Unresolved = {
ExportLoc, ParsedModuleId, Wildcard
};
ActiveModule->UnresolvedExports.push_back(Unresolved);
}
[modules] Restrict the module use-declaration to only appear in top-level modules, and allow sub-modules of a module with a use-declaration to make use of the nominated modules. llvm-svn: 233323
2015-03-27 06:10:01 +08:00
/// \brief Parse a module use declaration.
Module use declarations (II) Review: http://llvm-reviews.chandlerc.com/D1546. I have picked up this patch form Lawrence (http://llvm-reviews.chandlerc.com/D1063) and did a few changes. From the original change description (updated as appropriate): This patch adds a check that ensures that modules only use modules they have so declared. To this end, it adds a statement on intended module use to the module.map grammar: use module-id A module can then only use headers from other modules if it 'uses' them. This enforcement is off by default, but may be turned on with the new option -fmodules-decluse. When enforcing the module semantics, we also need to consider a source file part of a module. This is achieved with a compiler option -fmodule-name=<module-id>. The compiler at present only applies restrictions to the module directly being built. llvm-svn: 191283
2013-09-24 17:14:14 +08:00
///
[modules] Restrict the module use-declaration to only appear in top-level modules, and allow sub-modules of a module with a use-declaration to make use of the nominated modules. llvm-svn: 233323
2015-03-27 06:10:01 +08:00
/// use-declaration:
/// 'use' wildcard-module-id
Module use declarations (II) Review: http://llvm-reviews.chandlerc.com/D1546. I have picked up this patch form Lawrence (http://llvm-reviews.chandlerc.com/D1063) and did a few changes. From the original change description (updated as appropriate): This patch adds a check that ensures that modules only use modules they have so declared. To this end, it adds a statement on intended module use to the module.map grammar: use module-id A module can then only use headers from other modules if it 'uses' them. This enforcement is off by default, but may be turned on with the new option -fmodules-decluse. When enforcing the module semantics, we also need to consider a source file part of a module. This is achieved with a compiler option -fmodule-name=<module-id>. The compiler at present only applies restrictions to the module directly being built. llvm-svn: 191283
2013-09-24 17:14:14 +08:00
void ModuleMapParser::parseUseDecl() {
assert(Tok.is(MMToken::UseKeyword));
[modules] Restrict the module use-declaration to only appear in top-level modules, and allow sub-modules of a module with a use-declaration to make use of the nominated modules. llvm-svn: 233323
2015-03-27 06:10:01 +08:00
auto KWLoc = consumeToken();
Module use declarations (II) Review: http://llvm-reviews.chandlerc.com/D1546. I have picked up this patch form Lawrence (http://llvm-reviews.chandlerc.com/D1063) and did a few changes. From the original change description (updated as appropriate): This patch adds a check that ensures that modules only use modules they have so declared. To this end, it adds a statement on intended module use to the module.map grammar: use module-id A module can then only use headers from other modules if it 'uses' them. This enforcement is off by default, but may be turned on with the new option -fmodules-decluse. When enforcing the module semantics, we also need to consider a source file part of a module. This is achieved with a compiler option -fmodule-name=<module-id>. The compiler at present only applies restrictions to the module directly being built. llvm-svn: 191283
2013-09-24 17:14:14 +08:00
// Parse the module-id.
ModuleId ParsedModuleId;
Allow string literals as module names. In order to make the migration to modules easier, it seems to be helpful to allow a 1:1 mapping between target names of a current build system and the corresponding C++ modules. As such targets commonly contain characters like "-". ":" and "/", allowing arbitrary quote-escaped strings seems to be a straightforward option. After several offline discussions, the precise mechanisms for C++ module names especially regarding submodules and import statements has yet to be determined. Thus, this patch only enables string literals as names inside the module map files which can be used by automatic module import (through #include). Also improve the error message on missing use-declarations. llvm-svn: 196573
2013-12-06 17:25:54 +08:00
parseModuleId(ParsedModuleId);
Module use declarations (II) Review: http://llvm-reviews.chandlerc.com/D1546. I have picked up this patch form Lawrence (http://llvm-reviews.chandlerc.com/D1063) and did a few changes. From the original change description (updated as appropriate): This patch adds a check that ensures that modules only use modules they have so declared. To this end, it adds a statement on intended module use to the module.map grammar: use module-id A module can then only use headers from other modules if it 'uses' them. This enforcement is off by default, but may be turned on with the new option -fmodules-decluse. When enforcing the module semantics, we also need to consider a source file part of a module. This is achieved with a compiler option -fmodule-name=<module-id>. The compiler at present only applies restrictions to the module directly being built. llvm-svn: 191283
2013-09-24 17:14:14 +08:00
[modules] Restrict the module use-declaration to only appear in top-level modules, and allow sub-modules of a module with a use-declaration to make use of the nominated modules. llvm-svn: 233323
2015-03-27 06:10:01 +08:00
if (ActiveModule->Parent)
Diags.Report(KWLoc, diag::err_mmap_use_decl_submodule);
else
ActiveModule->UnresolvedDirectUses.push_back(ParsedModuleId);
Module use declarations (II) Review: http://llvm-reviews.chandlerc.com/D1546. I have picked up this patch form Lawrence (http://llvm-reviews.chandlerc.com/D1063) and did a few changes. From the original change description (updated as appropriate): This patch adds a check that ensures that modules only use modules they have so declared. To this end, it adds a statement on intended module use to the module.map grammar: use module-id A module can then only use headers from other modules if it 'uses' them. This enforcement is off by default, but may be turned on with the new option -fmodules-decluse. When enforcing the module semantics, we also need to consider a source file part of a module. This is achieved with a compiler option -fmodule-name=<module-id>. The compiler at present only applies restrictions to the module directly being built. llvm-svn: 191283
2013-09-24 17:14:14 +08:00
}
Implement parsing, AST, (de-)serialization, and placeholder global metadata for linking against the libraries/frameworks for imported modules. The module map language is extended with a new "link" directive that specifies what library or framework to link against when a module is imported, e.g., link "clangAST" or link framework "MyFramework" Importing the corresponding module (or any of its submodules) will eventually link against the named library/framework. For now, I've added some placeholder global metadata that encodes the imported libraries/frameworks, so that we can test that this information gets through to the IR. The format of the data is still under discussion. llvm-svn: 172437
2013-01-15 01:21:00 +08:00
/// \brief Parse a link declaration.
///
/// module-declaration:
/// 'link' 'framework'[opt] string-literal
void ModuleMapParser::parseLinkDecl() {
assert(Tok.is(MMToken::LinkKeyword));
SourceLocation LinkLoc = consumeToken();
// Parse the optional 'framework' keyword.
bool IsFramework = false;
if (Tok.is(MMToken::FrameworkKeyword)) {
consumeToken();
IsFramework = true;
}
// Parse the library name
if (!Tok.is(MMToken::StringLiteral)) {
Diags.Report(Tok.getLocation(), diag::err_mmap_expected_library_name)
<< IsFramework << SourceRange(LinkLoc);
HadError = true;
return;
}
std::string LibraryName = Tok.getString();
consumeToken();
ActiveModule->LinkLibraries.push_back(Module::LinkLibrary(LibraryName,
IsFramework));
}
<rdar://problem/10796651> Introduce configuration macros into module maps. Configuration macros are macros that are intended to alter how a module works, such that we need to build different module variants for different values of these macros. A module can declare its configuration macros, in which case we will complain if the definition of a configation macro on the command line (or lack thereof) differs from the current preprocessor state at the point where the module is imported. This should eliminate some surprises when enabling modules, because "#define CONFIG_MACRO ..." followed by "#include <module/header.h>" would silently ignore the CONFIG_MACRO setting. At least it will no longer be silent about it. Configuration macros are eventually intended to help reduce the number of module variants that need to be built. When the list of configuration macros for a module is exhaustive, we only need to consider the settings for those macros when building/finding the module, which can help isolate modules for various project-specific -D flags that should never affect how modules are build (but currently do). llvm-svn: 177466
2013-03-20 08:22:05 +08:00
/// \brief Parse a configuration macro declaration.
///
/// module-declaration:
/// 'config_macros' attributes[opt] config-macro-list?
///
/// config-macro-list:
/// identifier (',' identifier)?
void ModuleMapParser::parseConfigMacros() {
assert(Tok.is(MMToken::ConfigMacros));
SourceLocation ConfigMacrosLoc = consumeToken();
// Only top-level modules can have configuration macros.
if (ActiveModule->Parent) {
Diags.Report(ConfigMacrosLoc, diag::err_mmap_config_macro_submodule);
}
// Parse the optional attributes.
Attributes Attrs;
[Modules] Don't swallow errors when parsing optional attributes. Differential Revision: http://reviews.llvm.org/D17787 llvm-svn: 262789
2016-03-06 12:20:05 +08:00
if (parseOptionalAttributes(Attrs))
return;
<rdar://problem/10796651> Introduce configuration macros into module maps. Configuration macros are macros that are intended to alter how a module works, such that we need to build different module variants for different values of these macros. A module can declare its configuration macros, in which case we will complain if the definition of a configation macro on the command line (or lack thereof) differs from the current preprocessor state at the point where the module is imported. This should eliminate some surprises when enabling modules, because "#define CONFIG_MACRO ..." followed by "#include <module/header.h>" would silently ignore the CONFIG_MACRO setting. At least it will no longer be silent about it. Configuration macros are eventually intended to help reduce the number of module variants that need to be built. When the list of configuration macros for a module is exhaustive, we only need to consider the settings for those macros when building/finding the module, which can help isolate modules for various project-specific -D flags that should never affect how modules are build (but currently do). llvm-svn: 177466
2013-03-20 08:22:05 +08:00
if (Attrs.IsExhaustive && !ActiveModule->Parent) {
ActiveModule->ConfigMacrosExhaustive = true;
}
// If we don't have an identifier, we're done.
[modules] Add support for 'textual header' directives. This allows a module to specify that it logically contains a file, but that said file is non-modular and intended for textual inclusion. This allows layering checks to work properly in the presence of such files. llvm-svn: 220448
2014-10-23 07:50:56 +08:00
// FIXME: Support macros with the same name as a keyword here.
<rdar://problem/10796651> Introduce configuration macros into module maps. Configuration macros are macros that are intended to alter how a module works, such that we need to build different module variants for different values of these macros. A module can declare its configuration macros, in which case we will complain if the definition of a configation macro on the command line (or lack thereof) differs from the current preprocessor state at the point where the module is imported. This should eliminate some surprises when enabling modules, because "#define CONFIG_MACRO ..." followed by "#include <module/header.h>" would silently ignore the CONFIG_MACRO setting. At least it will no longer be silent about it. Configuration macros are eventually intended to help reduce the number of module variants that need to be built. When the list of configuration macros for a module is exhaustive, we only need to consider the settings for those macros when building/finding the module, which can help isolate modules for various project-specific -D flags that should never affect how modules are build (but currently do). llvm-svn: 177466
2013-03-20 08:22:05 +08:00
if (!Tok.is(MMToken::Identifier))
return;
// Consume the first identifier.
if (!ActiveModule->Parent) {
ActiveModule->ConfigMacros.push_back(Tok.getString().str());
}
consumeToken();
do {
// If there's a comma, consume it.
if (!Tok.is(MMToken::Comma))
break;
consumeToken();
// We expect to see a macro name here.
[modules] Add support for 'textual header' directives. This allows a module to specify that it logically contains a file, but that said file is non-modular and intended for textual inclusion. This allows layering checks to work properly in the presence of such files. llvm-svn: 220448
2014-10-23 07:50:56 +08:00
// FIXME: Support macros with the same name as a keyword here.
<rdar://problem/10796651> Introduce configuration macros into module maps. Configuration macros are macros that are intended to alter how a module works, such that we need to build different module variants for different values of these macros. A module can declare its configuration macros, in which case we will complain if the definition of a configation macro on the command line (or lack thereof) differs from the current preprocessor state at the point where the module is imported. This should eliminate some surprises when enabling modules, because "#define CONFIG_MACRO ..." followed by "#include <module/header.h>" would silently ignore the CONFIG_MACRO setting. At least it will no longer be silent about it. Configuration macros are eventually intended to help reduce the number of module variants that need to be built. When the list of configuration macros for a module is exhaustive, we only need to consider the settings for those macros when building/finding the module, which can help isolate modules for various project-specific -D flags that should never affect how modules are build (but currently do). llvm-svn: 177466
2013-03-20 08:22:05 +08:00
if (!Tok.is(MMToken::Identifier)) {
Diags.Report(Tok.getLocation(), diag::err_mmap_expected_config_macro);
break;
}
// Consume the macro name.
if (!ActiveModule->Parent) {
ActiveModule->ConfigMacros.push_back(Tok.getString().str());
}
consumeToken();
} while (true);
}
<rdar://problem/12368093> Extend module maps with a 'conflict' declaration, and warn when a newly-imported module conflicts with an already-imported module. llvm-svn: 177577
2013-03-21 05:10:35 +08:00
/// \brief Format a module-id into a string.
static std::string formatModuleId(const ModuleId &Id) {
std::string result;
{
llvm::raw_string_ostream OS(result);
for (unsigned I = 0, N = Id.size(); I != N; ++I) {
if (I)
OS << ".";
OS << Id[I].first;
}
}
return result;
}
/// \brief Parse a conflict declaration.
///
/// module-declaration:
/// 'conflict' module-id ',' string-literal
void ModuleMapParser::parseConflict() {
assert(Tok.is(MMToken::Conflict));
SourceLocation ConflictLoc = consumeToken();
Module::UnresolvedConflict Conflict;
// Parse the module-id.
if (parseModuleId(Conflict.Id))
return;
// Parse the ','.
if (!Tok.is(MMToken::Comma)) {
Diags.Report(Tok.getLocation(), diag::err_mmap_expected_conflicts_comma)
<< SourceRange(ConflictLoc);
return;
}
consumeToken();
// Parse the message.
if (!Tok.is(MMToken::StringLiteral)) {
Diags.Report(Tok.getLocation(), diag::err_mmap_expected_conflicts_message)
<< formatModuleId(Conflict.Id);
return;
}
Conflict.Message = Tok.getString().str();
consumeToken();
// Add this unresolved conflict.
ActiveModule->UnresolvedConflicts.push_back(Conflict);
}
Implement parsing, AST, (de-)serialization, and placeholder global metadata for linking against the libraries/frameworks for imported modules. The module map language is extended with a new "link" directive that specifies what library or framework to link against when a module is imported, e.g., link "clangAST" or link framework "MyFramework" Importing the corresponding module (or any of its submodules) will eventually link against the named library/framework. For now, I've added some placeholder global metadata that encodes the imported libraries/frameworks, so that we can test that this information gets through to the IR. The format of the data is still under discussion. llvm-svn: 172437
2013-01-15 01:21:00 +08:00
/// \brief Parse an inferred module declaration (wildcard modules).
Introduce inferred framework modules into the module map file, allowing a module map to be placed one level above the '.framework' directories to specify that all .frameworks within that directory can be inferred as framework modules. One can also specifically exclude frameworks known not to work. This makes explicit (and more restricted) behavior modules have had "forever", where *any* .framework was assumed to be able to be built as a module. That's not necessarily true, so we white-list directories (with exclusions) when those directories have been audited. llvm-svn: 167482
2012-11-07 03:39:40 +08:00
///
/// module-declaration:
/// 'explicit'[opt] 'framework'[opt] 'module' * attributes[opt]
/// { inferred-module-member* }
///
/// inferred-module-member:
/// 'export' '*'
/// 'exclude' identifier
void ModuleMapParser::parseInferredModuleDecl(bool Framework, bool Explicit) {
Parse inferred submodules in module maps, track their contents in Module, and (de-)serialize this information. Semantics of inferred submodules to follow. llvm-svn: 145864
2011-12-06 06:27:44 +08:00
assert(Tok.is(MMToken::Star));
SourceLocation StarLoc = consumeToken();
bool Failed = false;
Introduce inferred framework modules into the module map file, allowing a module map to be placed one level above the '.framework' directories to specify that all .frameworks within that directory can be inferred as framework modules. One can also specifically exclude frameworks known not to work. This makes explicit (and more restricted) behavior modules have had "forever", where *any* .framework was assumed to be able to be built as a module. That's not necessarily true, so we white-list directories (with exclusions) when those directories have been audited. llvm-svn: 167482
2012-11-07 03:39:40 +08:00
Parse inferred submodules in module maps, track their contents in Module, and (de-)serialize this information. Semantics of inferred submodules to follow. llvm-svn: 145864
2011-12-06 06:27:44 +08:00
// Inferred modules must be submodules.
Introduce inferred framework modules into the module map file, allowing a module map to be placed one level above the '.framework' directories to specify that all .frameworks within that directory can be inferred as framework modules. One can also specifically exclude frameworks known not to work. This makes explicit (and more restricted) behavior modules have had "forever", where *any* .framework was assumed to be able to be built as a module. That's not necessarily true, so we white-list directories (with exclusions) when those directories have been audited. llvm-svn: 167482
2012-11-07 03:39:40 +08:00
if (!ActiveModule && !Framework) {
Parse inferred submodules in module maps, track their contents in Module, and (de-)serialize this information. Semantics of inferred submodules to follow. llvm-svn: 145864
2011-12-06 06:27:44 +08:00
Diags.Report(StarLoc, diag::err_mmap_top_level_inferred_submodule);
Failed = true;
}
Introduce inferred framework modules into the module map file, allowing a module map to be placed one level above the '.framework' directories to specify that all .frameworks within that directory can be inferred as framework modules. One can also specifically exclude frameworks known not to work. This makes explicit (and more restricted) behavior modules have had "forever", where *any* .framework was assumed to be able to be built as a module. That's not necessarily true, so we white-list directories (with exclusions) when those directories have been audited. llvm-svn: 167482
2012-11-07 03:39:40 +08:00
if (ActiveModule) {
// Inferred modules must have umbrella directories.
Allow submodule inferrences with a missing umbrella when the module is unavailable If the module is unavailable because of a missing header, don't diagnose a "module * {}" declaration for having a missing umbrella. llvm-svn: 206776
2014-04-22 03:49:57 +08:00
if (!Failed && ActiveModule->IsAvailable &&
!ActiveModule->getUmbrellaDir()) {
Introduce inferred framework modules into the module map file, allowing a module map to be placed one level above the '.framework' directories to specify that all .frameworks within that directory can be inferred as framework modules. One can also specifically exclude frameworks known not to work. This makes explicit (and more restricted) behavior modules have had "forever", where *any* .framework was assumed to be able to be built as a module. That's not necessarily true, so we white-list directories (with exclusions) when those directories have been audited. llvm-svn: 167482
2012-11-07 03:39:40 +08:00
Diags.Report(StarLoc, diag::err_mmap_inferred_no_umbrella);
Failed = true;
}
// Check for redefinition of an inferred module.
if (!Failed && ActiveModule->InferSubmodules) {
Diags.Report(StarLoc, diag::err_mmap_inferred_redef);
if (ActiveModule->InferredSubmoduleLoc.isValid())
Diags.Report(ActiveModule->InferredSubmoduleLoc,
diag::note_mmap_prev_definition);
Failed = true;
}
// Check for the 'framework' keyword, which is not permitted here.
if (Framework) {
Diags.Report(StarLoc, diag::err_mmap_inferred_framework_submodule);
Framework = false;
}
} else if (Explicit) {
Diags.Report(StarLoc, diag::err_mmap_explicit_inferred_framework);
Explicit = false;
Parse inferred submodules in module maps, track their contents in Module, and (de-)serialize this information. Semantics of inferred submodules to follow. llvm-svn: 145864
2011-12-06 06:27:44 +08:00
}
Introduce inferred framework modules into the module map file, allowing a module map to be placed one level above the '.framework' directories to specify that all .frameworks within that directory can be inferred as framework modules. One can also specifically exclude frameworks known not to work. This makes explicit (and more restricted) behavior modules have had "forever", where *any* .framework was assumed to be able to be built as a module. That's not necessarily true, so we white-list directories (with exclusions) when those directories have been audited. llvm-svn: 167482
2012-11-07 03:39:40 +08:00
Parse inferred submodules in module maps, track their contents in Module, and (de-)serialize this information. Semantics of inferred submodules to follow. llvm-svn: 145864
2011-12-06 06:27:44 +08:00
// If there were any problems with this inferred submodule, skip its body.
if (Failed) {
if (Tok.is(MMToken::LBrace)) {
consumeToken();
skipUntil(MMToken::RBrace);
if (Tok.is(MMToken::RBrace))
consumeToken();
}
HadError = true;
return;
}
Introduce inferred framework modules into the module map file, allowing a module map to be placed one level above the '.framework' directories to specify that all .frameworks within that directory can be inferred as framework modules. One can also specifically exclude frameworks known not to work. This makes explicit (and more restricted) behavior modules have had "forever", where *any* .framework was assumed to be able to be built as a module. That's not necessarily true, so we white-list directories (with exclusions) when those directories have been audited. llvm-svn: 167482
2012-11-07 03:39:40 +08:00
// Parse optional attributes.
Revert r170500. It over-zealously converted *ALL* things named Attributes, which is wrong here. llvm-svn: 170721
2012-12-21 03:22:21 +08:00
Attributes Attrs;
[Modules] Don't swallow errors when parsing optional attributes. Differential Revision: http://reviews.llvm.org/D17787 llvm-svn: 262789
2016-03-06 12:20:05 +08:00
if (parseOptionalAttributes(Attrs))
return;
Introduce inferred framework modules into the module map file, allowing a module map to be placed one level above the '.framework' directories to specify that all .frameworks within that directory can be inferred as framework modules. One can also specifically exclude frameworks known not to work. This makes explicit (and more restricted) behavior modules have had "forever", where *any* .framework was assumed to be able to be built as a module. That's not necessarily true, so we white-list directories (with exclusions) when those directories have been audited. llvm-svn: 167482
2012-11-07 03:39:40 +08:00
if (ActiveModule) {
// Note that we have an inferred submodule.
ActiveModule->InferSubmodules = true;
ActiveModule->InferredSubmoduleLoc = StarLoc;
ActiveModule->InferExplicitSubmodules = Explicit;
} else {
// We'll be inferring framework modules for this directory.
Map.InferredDirectories[Directory].InferModules = true;
Inherit attributes when infering a framework module If a module map contains framework module * [extern_c] {} We will now infer [extern_c] on the inferred framework modules (we already inferred [system] as a special case). llvm-svn: 225803
2015-01-14 01:47:44 +08:00
Map.InferredDirectories[Directory].Attrs = Attrs;
Allow multiple modules with the same name to coexist in the module cache To differentiate between two modules with the same name, we will consider the path the module map file that they are defined by* part of the ‘key’ for looking up the precompiled module (pcm file). Specifically, this patch renames the precompiled module (pcm) files from cache-path/<module hash>/Foo.pcm to cache-path/<module hash>/Foo-<hash of module map path>.pcm In addition, I’ve taught the ASTReader to re-resolve the names of imported modules during module loading so that if the header search context changes between when a module was originally built and when it is loaded we can rebuild it if necessary. For example, if module A imports module B first time: clang -I /path/to/A -I /path/to/B ... second time: clang -I /path/to/A -I /different/path/to/B ... will now rebuild A as expected. * in the case of inferred modules, we use the module map file that allowed the inference, not the __inferred_module.map file, since the inferred file path is the same for every inferred module. llvm-svn: 206201
2014-04-15 02:00:01 +08:00
Map.InferredDirectories[Directory].ModuleMapFile = ModuleMapFile;
Remove a dead store, add a FIXME for another. llvm-svn: 203169
2014-03-07 05:59:38 +08:00
// FIXME: Handle the 'framework' keyword.
Introduce inferred framework modules into the module map file, allowing a module map to be placed one level above the '.framework' directories to specify that all .frameworks within that directory can be inferred as framework modules. One can also specifically exclude frameworks known not to work. This makes explicit (and more restricted) behavior modules have had "forever", where *any* .framework was assumed to be able to be built as a module. That's not necessarily true, so we white-list directories (with exclusions) when those directories have been audited. llvm-svn: 167482
2012-11-07 03:39:40 +08:00
}
Parse inferred submodules in module maps, track their contents in Module, and (de-)serialize this information. Semantics of inferred submodules to follow. llvm-svn: 145864
2011-12-06 06:27:44 +08:00
// Parse the opening brace.
if (!Tok.is(MMToken::LBrace)) {
Diags.Report(Tok.getLocation(), diag::err_mmap_expected_lbrace_wildcard);
HadError = true;
return;
}
SourceLocation LBraceLoc = consumeToken();
// Parse the body of the inferred submodule.
bool Done = false;
do {
switch (Tok.Kind) {
case MMToken::EndOfFile:
case MMToken::RBrace:
Done = true;
break;
Introduce inferred framework modules into the module map file, allowing a module map to be placed one level above the '.framework' directories to specify that all .frameworks within that directory can be inferred as framework modules. One can also specifically exclude frameworks known not to work. This makes explicit (and more restricted) behavior modules have had "forever", where *any* .framework was assumed to be able to be built as a module. That's not necessarily true, so we white-list directories (with exclusions) when those directories have been audited. llvm-svn: 167482
2012-11-07 03:39:40 +08:00
case MMToken::ExcludeKeyword: {
if (ActiveModule) {
Diags.Report(Tok.getLocation(), diag::err_mmap_expected_inferred_member)
[C++11] Use 'nullptr'. Lex edition. llvm-svn: 209083
2014-05-18 07:10:59 +08:00
<< (ActiveModule != nullptr);
Introduce inferred framework modules into the module map file, allowing a module map to be placed one level above the '.framework' directories to specify that all .frameworks within that directory can be inferred as framework modules. One can also specifically exclude frameworks known not to work. This makes explicit (and more restricted) behavior modules have had "forever", where *any* .framework was assumed to be able to be built as a module. That's not necessarily true, so we white-list directories (with exclusions) when those directories have been audited. llvm-svn: 167482
2012-11-07 03:39:40 +08:00
consumeToken();
break;
}
consumeToken();
[modules] Add support for 'textual header' directives. This allows a module to specify that it logically contains a file, but that said file is non-modular and intended for textual inclusion. This allows layering checks to work properly in the presence of such files. llvm-svn: 220448
2014-10-23 07:50:56 +08:00
// FIXME: Support string-literal module names here.
Introduce inferred framework modules into the module map file, allowing a module map to be placed one level above the '.framework' directories to specify that all .frameworks within that directory can be inferred as framework modules. One can also specifically exclude frameworks known not to work. This makes explicit (and more restricted) behavior modules have had "forever", where *any* .framework was assumed to be able to be built as a module. That's not necessarily true, so we white-list directories (with exclusions) when those directories have been audited. llvm-svn: 167482
2012-11-07 03:39:40 +08:00
if (!Tok.is(MMToken::Identifier)) {
Diags.Report(Tok.getLocation(), diag::err_mmap_missing_exclude_name);
break;
}
Map.InferredDirectories[Directory].ExcludedModules
.push_back(Tok.getString());
consumeToken();
break;
}
case MMToken::ExportKeyword:
if (!ActiveModule) {
Diags.Report(Tok.getLocation(), diag::err_mmap_expected_inferred_member)
[C++11] Use 'nullptr'. Lex edition. llvm-svn: 209083
2014-05-18 07:10:59 +08:00
<< (ActiveModule != nullptr);
Introduce inferred framework modules into the module map file, allowing a module map to be placed one level above the '.framework' directories to specify that all .frameworks within that directory can be inferred as framework modules. One can also specifically exclude frameworks known not to work. This makes explicit (and more restricted) behavior modules have had "forever", where *any* .framework was assumed to be able to be built as a module. That's not necessarily true, so we white-list directories (with exclusions) when those directories have been audited. llvm-svn: 167482
2012-11-07 03:39:40 +08:00
consumeToken();
break;
}
Parse inferred submodules in module maps, track their contents in Module, and (de-)serialize this information. Semantics of inferred submodules to follow. llvm-svn: 145864
2011-12-06 06:27:44 +08:00
consumeToken();
if (Tok.is(MMToken::Star))
Allow inferred submodules for any (sub)module that has an umbrella header llvm-svn: 145945
2011-12-07 01:34:58 +08:00
ActiveModule->InferExportWildcard = true;
Parse inferred submodules in module maps, track their contents in Module, and (de-)serialize this information. Semantics of inferred submodules to follow. llvm-svn: 145864
2011-12-06 06:27:44 +08:00
else
Diags.Report(Tok.getLocation(),
diag::err_mmap_expected_export_wildcard);
consumeToken();
break;
Introduce inferred framework modules into the module map file, allowing a module map to be placed one level above the '.framework' directories to specify that all .frameworks within that directory can be inferred as framework modules. One can also specifically exclude frameworks known not to work. This makes explicit (and more restricted) behavior modules have had "forever", where *any* .framework was assumed to be able to be built as a module. That's not necessarily true, so we white-list directories (with exclusions) when those directories have been audited. llvm-svn: 167482
2012-11-07 03:39:40 +08:00
Parse inferred submodules in module maps, track their contents in Module, and (de-)serialize this information. Semantics of inferred submodules to follow. llvm-svn: 145864
2011-12-06 06:27:44 +08:00
case MMToken::ExplicitKeyword:
case MMToken::ModuleKeyword:
case MMToken::HeaderKeyword:
This patch adds new private headers to the module map. Private headers may be included from within the module, but not from outside the module. llvm-svn: 184471
2013-06-21 05:14:14 +08:00
case MMToken::PrivateKeyword:
Parse inferred submodules in module maps, track their contents in Module, and (de-)serialize this information. Semantics of inferred submodules to follow. llvm-svn: 145864
2011-12-06 06:27:44 +08:00
case MMToken::UmbrellaKeyword:
default:
Introduce inferred framework modules into the module map file, allowing a module map to be placed one level above the '.framework' directories to specify that all .frameworks within that directory can be inferred as framework modules. One can also specifically exclude frameworks known not to work. This makes explicit (and more restricted) behavior modules have had "forever", where *any* .framework was assumed to be able to be built as a module. That's not necessarily true, so we white-list directories (with exclusions) when those directories have been audited. llvm-svn: 167482
2012-11-07 03:39:40 +08:00
Diags.Report(Tok.getLocation(), diag::err_mmap_expected_inferred_member)
[C++11] Use 'nullptr'. Lex edition. llvm-svn: 209083
2014-05-18 07:10:59 +08:00
<< (ActiveModule != nullptr);
Parse inferred submodules in module maps, track their contents in Module, and (de-)serialize this information. Semantics of inferred submodules to follow. llvm-svn: 145864
2011-12-06 06:27:44 +08:00
consumeToken();
break;
}
} while (!Done);
if (Tok.is(MMToken::RBrace))
consumeToken();
else {
Diags.Report(Tok.getLocation(), diag::err_mmap_expected_rbrace);
Diags.Report(LBraceLoc, diag::note_mmap_lbrace_match);
HadError = true;
}
}
Introduce inferred framework modules into the module map file, allowing a module map to be placed one level above the '.framework' directories to specify that all .frameworks within that directory can be inferred as framework modules. One can also specifically exclude frameworks known not to work. This makes explicit (and more restricted) behavior modules have had "forever", where *any* .framework was assumed to be able to be built as a module. That's not necessarily true, so we white-list directories (with exclusions) when those directories have been audited. llvm-svn: 167482
2012-11-07 03:39:40 +08:00
/// \brief Parse optional attributes.
///
/// attributes:
/// attribute attributes
/// attribute
///
/// attribute:
/// [ identifier ]
///
/// \param Attrs Will be filled in with the parsed attributes.
///
/// \returns true if an error occurred, false otherwise.
Revert r170500. It over-zealously converted *ALL* things named Attributes, which is wrong here. llvm-svn: 170721
2012-12-21 03:22:21 +08:00
bool ModuleMapParser::parseOptionalAttributes(Attributes &Attrs) {
Introduce inferred framework modules into the module map file, allowing a module map to be placed one level above the '.framework' directories to specify that all .frameworks within that directory can be inferred as framework modules. One can also specifically exclude frameworks known not to work. This makes explicit (and more restricted) behavior modules have had "forever", where *any* .framework was assumed to be able to be built as a module. That's not necessarily true, so we white-list directories (with exclusions) when those directories have been audited. llvm-svn: 167482
2012-11-07 03:39:40 +08:00
bool HadError = false;
while (Tok.is(MMToken::LSquare)) {
// Consume the '['.
SourceLocation LSquareLoc = consumeToken();
// Check whether we have an attribute name here.
if (!Tok.is(MMToken::Identifier)) {
Diags.Report(Tok.getLocation(), diag::err_mmap_expected_attribute);
skipUntil(MMToken::RSquare);
if (Tok.is(MMToken::RSquare))
consumeToken();
HadError = true;
}
// Decode the attribute name.
AttributeKind Attribute
= llvm::StringSwitch<AttributeKind>(Tok.getString())
<rdar://problem/10796651> Introduce configuration macros into module maps. Configuration macros are macros that are intended to alter how a module works, such that we need to build different module variants for different values of these macros. A module can declare its configuration macros, in which case we will complain if the definition of a configation macro on the command line (or lack thereof) differs from the current preprocessor state at the point where the module is imported. This should eliminate some surprises when enabling modules, because "#define CONFIG_MACRO ..." followed by "#include <module/header.h>" would silently ignore the CONFIG_MACRO setting. At least it will no longer be silent about it. Configuration macros are eventually intended to help reduce the number of module variants that need to be built. When the list of configuration macros for a module is exhaustive, we only need to consider the settings for those macros when building/finding the module, which can help isolate modules for various project-specific -D flags that should never affect how modules are build (but currently do). llvm-svn: 177466
2013-03-20 08:22:05 +08:00
.Case("exhaustive", AT_exhaustive)
Add [extern_c] attribute for modules, allowing a C module to be imported within an extern "C" block in C++ code. llvm-svn: 202615
2014-03-02 13:58:18 +08:00
.Case("extern_c", AT_extern_c)
[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
2016-10-21 09:41:56 +08:00
.Case("no_undeclared_includes", AT_no_undeclared_includes)
Introduce inferred framework modules into the module map file, allowing a module map to be placed one level above the '.framework' directories to specify that all .frameworks within that directory can be inferred as framework modules. One can also specifically exclude frameworks known not to work. This makes explicit (and more restricted) behavior modules have had "forever", where *any* .framework was assumed to be able to be built as a module. That's not necessarily true, so we white-list directories (with exclusions) when those directories have been audited. llvm-svn: 167482
2012-11-07 03:39:40 +08:00
.Case("system", AT_system)
.Default(AT_unknown);
switch (Attribute) {
case AT_unknown:
Diags.Report(Tok.getLocation(), diag::warn_mmap_unknown_attribute)
<< Tok.getString();
break;
case AT_system:
Attrs.IsSystem = true;
break;
<rdar://problem/10796651> Introduce configuration macros into module maps. Configuration macros are macros that are intended to alter how a module works, such that we need to build different module variants for different values of these macros. A module can declare its configuration macros, in which case we will complain if the definition of a configation macro on the command line (or lack thereof) differs from the current preprocessor state at the point where the module is imported. This should eliminate some surprises when enabling modules, because "#define CONFIG_MACRO ..." followed by "#include <module/header.h>" would silently ignore the CONFIG_MACRO setting. At least it will no longer be silent about it. Configuration macros are eventually intended to help reduce the number of module variants that need to be built. When the list of configuration macros for a module is exhaustive, we only need to consider the settings for those macros when building/finding the module, which can help isolate modules for various project-specific -D flags that should never affect how modules are build (but currently do). llvm-svn: 177466
2013-03-20 08:22:05 +08:00
Add [extern_c] attribute for modules, allowing a C module to be imported within an extern "C" block in C++ code. llvm-svn: 202615
2014-03-02 13:58:18 +08:00
case AT_extern_c:
Attrs.IsExternC = true;
break;
<rdar://problem/10796651> Introduce configuration macros into module maps. Configuration macros are macros that are intended to alter how a module works, such that we need to build different module variants for different values of these macros. A module can declare its configuration macros, in which case we will complain if the definition of a configation macro on the command line (or lack thereof) differs from the current preprocessor state at the point where the module is imported. This should eliminate some surprises when enabling modules, because "#define CONFIG_MACRO ..." followed by "#include <module/header.h>" would silently ignore the CONFIG_MACRO setting. At least it will no longer be silent about it. Configuration macros are eventually intended to help reduce the number of module variants that need to be built. When the list of configuration macros for a module is exhaustive, we only need to consider the settings for those macros when building/finding the module, which can help isolate modules for various project-specific -D flags that should never affect how modules are build (but currently do). llvm-svn: 177466
2013-03-20 08:22:05 +08:00
case AT_exhaustive:
Attrs.IsExhaustive = true;
break;
[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
2016-10-21 09:41:56 +08:00
case AT_no_undeclared_includes:
Attrs.NoUndeclaredIncludes = true;
break;
Introduce inferred framework modules into the module map file, allowing a module map to be placed one level above the '.framework' directories to specify that all .frameworks within that directory can be inferred as framework modules. One can also specifically exclude frameworks known not to work. This makes explicit (and more restricted) behavior modules have had "forever", where *any* .framework was assumed to be able to be built as a module. That's not necessarily true, so we white-list directories (with exclusions) when those directories have been audited. llvm-svn: 167482
2012-11-07 03:39:40 +08:00
}
consumeToken();
// Consume the ']'.
if (!Tok.is(MMToken::RSquare)) {
Diags.Report(Tok.getLocation(), diag::err_mmap_expected_rsquare);
Diags.Report(LSquareLoc, diag::note_mmap_lsquare_match);
skipUntil(MMToken::RSquare);
HadError = true;
}
if (Tok.is(MMToken::RSquare))
consumeToken();
}
return HadError;
}
Introduce basic support for parsing module map files. Module map files provide a way to map between headers and modules, so that we can layer a module system on top of existing headers without changing those headers at all. This commit introduces the module map file parser and the module map that it generates, and wires up the module map file parser so that we'll automatically find module map files as part of header search. Note that we don't yet use the information stored in the module map. llvm-svn: 144402
2011-11-12 03:10:28 +08:00
/// \brief Parse a module map file.
///
/// module-map-file:
/// module-declaration*
bool ModuleMapParser::parseModuleMapFile() {
do {
switch (Tok.Kind) {
case MMToken::EndOfFile:
return HadError;
Implement basic support for private headers in frameworks. In essence, when we load a module map (module.map) from a directory, also load a private module map (module_private.map) for that directory, if present. That private module map can inject a new submodule that captures private headers. llvm-svn: 146012
2011-12-07 10:23:45 +08:00
case MMToken::ExplicitKeyword:
Support for modular module-map-files This patch is the first step to make module-map-files modular (instead of requiring a single "module.map"-file per include directory). This step adds a new "extern module" declaration that enables module-map-files to reference one another along with a very basic implementation. The next steps are: * Combine this with the use-declaration (from http://llvm-reviews.chandlerc.com/D1546) in order to only load module map files required for a specific compilation. * Add an additional flag to start with a specific module-map-file (instead of requiring there to be at least one "module.map"). Review: http://llvm-reviews.chandlerc.com/D1637 llvm-svn: 190497
2013-09-11 15:20:44 +08:00
case MMToken::ExternKeyword:
Introduce basic support for parsing module map files. Module map files provide a way to map between headers and modules, so that we can layer a module system on top of existing headers without changing those headers at all. This commit introduces the module map file parser and the module map that it generates, and wires up the module map file parser so that we'll automatically find module map files as part of header search. Note that we don't yet use the information stored in the module map. llvm-svn: 144402
2011-11-12 03:10:28 +08:00
case MMToken::ModuleKeyword:
Add the notion of "framework" modules to module maps. Framework modules (obviously) describe frameworks, and understand the header layout of frameworks. llvm-svn: 144921
2011-11-18 06:09:43 +08:00
case MMToken::FrameworkKeyword:
Introduce basic support for parsing module map files. Module map files provide a way to map between headers and modules, so that we can layer a module system on top of existing headers without changing those headers at all. This commit introduces the module map file parser and the module map that it generates, and wires up the module map file parser so that we'll automatically find module map files as part of header search. Note that we don't yet use the information stored in the module map. llvm-svn: 144402
2011-11-12 03:10:28 +08:00
parseModuleDecl();
break;
Implement parsing, AST, (de-)serialization, and placeholder global metadata for linking against the libraries/frameworks for imported modules. The module map language is extended with a new "link" directive that specifies what library or framework to link against when a module is imported, e.g., link "clangAST" or link framework "MyFramework" Importing the corresponding module (or any of its submodules) will eventually link against the named library/framework. For now, I've added some placeholder global metadata that encodes the imported libraries/frameworks, so that we can test that this information gets through to the IR. The format of the data is still under discussion. llvm-svn: 172437
2013-01-15 01:21:00 +08:00
Implement support for module requirements, which indicate the language features needed for a particular module to be available. This allows mixed-language modules, where certain headers only work under some language variants (e.g., in C++, std.tuple might only be available in C++11 mode). llvm-svn: 147387
2011-12-31 12:05:44 +08:00
case MMToken::Comma:
<rdar://problem/10796651> Introduce configuration macros into module maps. Configuration macros are macros that are intended to alter how a module works, such that we need to build different module variants for different values of these macros. A module can declare its configuration macros, in which case we will complain if the definition of a configation macro on the command line (or lack thereof) differs from the current preprocessor state at the point where the module is imported. This should eliminate some surprises when enabling modules, because "#define CONFIG_MACRO ..." followed by "#include <module/header.h>" would silently ignore the CONFIG_MACRO setting. At least it will no longer be silent about it. Configuration macros are eventually intended to help reduce the number of module variants that need to be built. When the list of configuration macros for a module is exhaustive, we only need to consider the settings for those macros when building/finding the module, which can help isolate modules for various project-specific -D flags that should never affect how modules are build (but currently do). llvm-svn: 177466
2013-03-20 08:22:05 +08:00
case MMToken::ConfigMacros:
<rdar://problem/12368093> Extend module maps with a 'conflict' declaration, and warn when a newly-imported module conflicts with an already-imported module. llvm-svn: 177577
2013-03-21 05:10:35 +08:00
case MMToken::Conflict:
Allow a new syntax in a module requires-declaration: requires ! feature The purpose of this is to allow (for instance) the module map for /usr/include to exclude <tgmath.h> and <complex.h> when building in C++ (these headers are instead provided by the C++ standard library in this case, and the glibc C <tgmath.h> header would otherwise try to include <complex.h>, resulting in a module cycle). llvm-svn: 193549
2013-10-29 06:18:19 +08:00
case MMToken::Exclaim:
Introduce the notion of excluded headers into the module map description. Previously, one could emulate this behavior by placing the header in an always-unavailable submodule, but Argyrios guilted me into expressing this idea properly. llvm-svn: 165921
2012-10-15 14:28:11 +08:00
case MMToken::ExcludeKeyword:
Implementing parsing and resolution of module export declarations within module maps, which will (eventually) be used to re-export a module from another module. There are still some pieces missing, however. llvm-svn: 145665
2011-12-02 09:47:07 +08:00
case MMToken::ExportKeyword:
Introduce basic support for parsing module map files. Module map files provide a way to map between headers and modules, so that we can layer a module system on top of existing headers without changing those headers at all. This commit introduces the module map file parser and the module map that it generates, and wires up the module map file parser so that we'll automatically find module map files as part of header search. Note that we don't yet use the information stored in the module map. llvm-svn: 144402
2011-11-12 03:10:28 +08:00
case MMToken::HeaderKeyword:
case MMToken::Identifier:
case MMToken::LBrace:
Implement parsing, AST, (de-)serialization, and placeholder global metadata for linking against the libraries/frameworks for imported modules. The module map language is extended with a new "link" directive that specifies what library or framework to link against when a module is imported, e.g., link "clangAST" or link framework "MyFramework" Importing the corresponding module (or any of its submodules) will eventually link against the named library/framework. For now, I've added some placeholder global metadata that encodes the imported libraries/frameworks, so that we can test that this information gets through to the IR. The format of the data is still under discussion. llvm-svn: 172437
2013-01-15 01:21:00 +08:00
case MMToken::LinkKeyword:
Introduce module attributes into the module map grammar, along with a single attribute ("system") that allows us to mark a module as being a "system" module. Each of the headers that makes up a system module is considered to be a system header, so that we (for example) suppress warnings there. If a module is being inferred for a framework, and that framework directory is within a system frameworks directory, infer it as a system framework. llvm-svn: 149143
2012-01-28 03:52:33 +08:00
case MMToken::LSquare:
Implementing parsing and resolution of module export declarations within module maps, which will (eventually) be used to re-export a module from another module. There are still some pieces missing, however. llvm-svn: 145665
2011-12-02 09:47:07 +08:00
case MMToken::Period:
This patch adds new private headers to the module map. Private headers may be included from within the module, but not from outside the module. llvm-svn: 184471
2013-06-21 05:14:14 +08:00
case MMToken::PrivateKeyword:
Introduce basic support for parsing module map files. Module map files provide a way to map between headers and modules, so that we can layer a module system on top of existing headers without changing those headers at all. This commit introduces the module map file parser and the module map that it generates, and wires up the module map file parser so that we'll automatically find module map files as part of header search. Note that we don't yet use the information stored in the module map. llvm-svn: 144402
2011-11-12 03:10:28 +08:00
case MMToken::RBrace:
Introduce module attributes into the module map grammar, along with a single attribute ("system") that allows us to mark a module as being a "system" module. Each of the headers that makes up a system module is considered to be a system header, so that we (for example) suppress warnings there. If a module is being inferred for a framework, and that framework directory is within a system frameworks directory, infer it as a system framework. llvm-svn: 149143
2012-01-28 03:52:33 +08:00
case MMToken::RSquare:
Implement support for module requirements, which indicate the language features needed for a particular module to be available. This allows mixed-language modules, where certain headers only work under some language variants (e.g., in C++, std.tuple might only be available in C++11 mode). llvm-svn: 147387
2011-12-31 12:05:44 +08:00
case MMToken::RequiresKeyword:
Implementing parsing and resolution of module export declarations within module maps, which will (eventually) be used to re-export a module from another module. There are still some pieces missing, however. llvm-svn: 145665
2011-12-02 09:47:07 +08:00
case MMToken::Star:
Introduce basic support for parsing module map files. Module map files provide a way to map between headers and modules, so that we can layer a module system on top of existing headers without changing those headers at all. This commit introduces the module map file parser and the module map that it generates, and wires up the module map file parser so that we'll automatically find module map files as part of header search. Note that we don't yet use the information stored in the module map. llvm-svn: 144402
2011-11-12 03:10:28 +08:00
case MMToken::StringLiteral:
Fix covered-switch warning. llvm-svn: 220456
2014-10-23 09:03:45 +08:00
case MMToken::TextualKeyword:
Introduce basic support for parsing module map files. Module map files provide a way to map between headers and modules, so that we can layer a module system on top of existing headers without changing those headers at all. This commit introduces the module map file parser and the module map that it generates, and wires up the module map file parser so that we'll automatically find module map files as part of header search. Note that we don't yet use the information stored in the module map. llvm-svn: 144402
2011-11-12 03:10:28 +08:00
case MMToken::UmbrellaKeyword:
Module use declarations (II) Review: http://llvm-reviews.chandlerc.com/D1546. I have picked up this patch form Lawrence (http://llvm-reviews.chandlerc.com/D1063) and did a few changes. From the original change description (updated as appropriate): This patch adds a check that ensures that modules only use modules they have so declared. To this end, it adds a statement on intended module use to the module.map grammar: use module-id A module can then only use headers from other modules if it 'uses' them. This enforcement is off by default, but may be turned on with the new option -fmodules-decluse. When enforcing the module semantics, we also need to consider a source file part of a module. This is achieved with a compiler option -fmodule-name=<module-id>. The compiler at present only applies restrictions to the module directly being built. llvm-svn: 191283
2013-09-24 17:14:14 +08:00
case MMToken::UseKeyword:
Introduce basic support for parsing module map files. Module map files provide a way to map between headers and modules, so that we can layer a module system on top of existing headers without changing those headers at all. This commit introduces the module map file parser and the module map that it generates, and wires up the module map file parser so that we'll automatically find module map files as part of header search. Note that we don't yet use the information stored in the module map. llvm-svn: 144402
2011-11-12 03:10:28 +08:00
Diags.Report(Tok.getLocation(), diag::err_mmap_expected_module);
HadError = true;
consumeToken();
break;
}
} while (true);
}
Reinstate r223753, reverted in r223759 due to breakage of clang-tools-extra. Original commit message: [modules] Add experimental -fmodule-map-file-home-is-cwd flag to -cc1. For files named by -fmodule-map-file=, and files found by 'extern module' directives, this flag specifies that we should resolve filenames relative to the current working directory rather than relative to the directory in which the module map file resides. This is aimed at fixing path handling, in particular for relative -I paths, when building modules that represent components of the current project (rather than libraries installed on the current system, which the current project has as dependencies, where we'd typically expect the module map files to be looked up implicitly). llvm-svn: 223913
2014-12-10 11:09:48 +08:00
bool ModuleMap::parseModuleMapFile(const FileEntry *File, bool IsSystem,
[modules] When diagnosing errors in module map files found by 'extern module' declarations, show how we got to that module map file. llvm-svn: 242105
2015-07-14 10:06:01 +08:00
const DirectoryEntry *Dir,
SourceLocation ExternModuleLoc) {
Rework the realpath nonsense for framework lookups to deal more uniformly with symlinks between top-level and embedded frameworks. llvm-svn: 172030
2013-01-10 09:43:00 +08:00
llvm::DenseMap<const FileEntry *, bool>::iterator Known
= ParsedModuleMap.find(File);
if (Known != ParsedModuleMap.end())
return Known->second;
[C++11] Use 'nullptr'. Lex edition. llvm-svn: 209083
2014-05-18 07:10:59 +08:00
assert(Target && "Missing target information");
Add dependencies from imported modules with -MD Add module dependencies to the dependency files created by -MD/-MMD/etc. by attaching an ASTReaderListener that will call into the dependency file generator when a module input file is seen in the serialized AST. llvm-svn: 203208
2014-03-07 14:40:32 +08:00
auto FileCharacter = IsSystem ? SrcMgr::C_System : SrcMgr::C_User;
[modules] When diagnosing errors in module map files found by 'extern module' declarations, show how we got to that module map file. llvm-svn: 242105
2015-07-14 10:06:01 +08:00
FileID ID = SourceMgr.createFileID(File, ExternModuleLoc, FileCharacter);
Use the same SourceManager for ModuleMaps and compilations. This allows using virtual file mappings on the original SourceManager to map in virtual module.map files. Without this patch, the ModuleMap search will find a module.map file (as the FileEntry exists in the FileManager), but will be unable to get the content from the SourceManager (as ModuleMap previously created its own SourceManager). Two problems needed to be fixed which this patch exposed: 1. Storing the inferred module map When writing out a module, the ASTWriter stores the names of the files in the main source manager; when loading the AST again, the ASTReader errs out if such a file is found missing, unless it is overridden. Previously CompilerInstance's compileModule method would store the inferred module map to a temporary file; the problem with this approach is that now that the module map is handled by the main source manager, the ASTWriter stores the name of the temporary module map as source to the compilation; later, when the module is loaded, the temporary file has already been deleted, which leads to a compilation error. This patch changes the inferred module map to instead inject a virtual file into the source manager. This both saves some disk IO, and works with how the ASTWriter/ASTReader handle overridden source files. 2. Changing test input in test/Modules/Inputs/* Now that the module map file is handled by the main source manager, the VerifyDiagnosticConsumer will not ignore diagnostics created while parsing the module map file. The module test test/Modules/renamed.m uses -I test/Modules/Inputs and triggers recursive loading of all module maps in test/Modules/Inputs, some of which had conflicting names, thus leading errors while parsing the module maps. Those diagnostics already occur on trunk, but before this patch they would not break the test, as they were ignored by the VerifyDiagnosticConsumer. This patch thus changes the module maps that have been recently introduced which broke the invariant of compatible modules maps in test/Modules/Inputs. llvm-svn: 193314
2013-10-24 15:51:24 +08:00
const llvm::MemoryBuffer *Buffer = SourceMgr.getBuffer(ID);
Introduce basic support for parsing module map files. Module map files provide a way to map between headers and modules, so that we can layer a module system on top of existing headers without changing those headers at all. This commit introduces the module map file parser and the module map that it generates, and wires up the module map file parser so that we'll automatically find module map files as part of header search. Note that we don't yet use the information stored in the module map. llvm-svn: 144402
2011-11-12 03:10:28 +08:00
if (!Buffer)
Rework the realpath nonsense for framework lookups to deal more uniformly with symlinks between top-level and embedded frameworks. llvm-svn: 172030
2013-01-10 09:43:00 +08:00
return ParsedModuleMap[File] = true;
Add a new spelling for module map files 'module.modulemap' This name, while more verbose, plays more nicely with tools that use file extensions to determine file types. The existing spelling 'module.map' will continue to work, but the new spelling will take precedence. In frameworks, this new filename will only go in a new 'Modules' sub-directory. Similarly, add a module.private.modulemap corresponding to module_private.map. llvm-svn: 204261
2014-03-20 04:23:34 +08:00
Introduce basic support for parsing module map files. Module map files provide a way to map between headers and modules, so that we can layer a module system on top of existing headers without changing those headers at all. This commit introduces the module map file parser and the module map that it generates, and wires up the module map file parser so that we'll automatically find module map files as part of header search. Note that we don't yet use the information stored in the module map. llvm-svn: 144402
2011-11-12 03:10:28 +08:00
// Parse this module map file.
Use the same SourceManager for ModuleMaps and compilations. This allows using virtual file mappings on the original SourceManager to map in virtual module.map files. Without this patch, the ModuleMap search will find a module.map file (as the FileEntry exists in the FileManager), but will be unable to get the content from the SourceManager (as ModuleMap previously created its own SourceManager). Two problems needed to be fixed which this patch exposed: 1. Storing the inferred module map When writing out a module, the ASTWriter stores the names of the files in the main source manager; when loading the AST again, the ASTReader errs out if such a file is found missing, unless it is overridden. Previously CompilerInstance's compileModule method would store the inferred module map to a temporary file; the problem with this approach is that now that the module map is handled by the main source manager, the ASTWriter stores the name of the temporary module map as source to the compilation; later, when the module is loaded, the temporary file has already been deleted, which leads to a compilation error. This patch changes the inferred module map to instead inject a virtual file into the source manager. This both saves some disk IO, and works with how the ASTWriter/ASTReader handle overridden source files. 2. Changing test input in test/Modules/Inputs/* Now that the module map file is handled by the main source manager, the VerifyDiagnosticConsumer will not ignore diagnostics created while parsing the module map file. The module test test/Modules/renamed.m uses -I test/Modules/Inputs and triggers recursive loading of all module maps in test/Modules/Inputs, some of which had conflicting names, thus leading errors while parsing the module maps. Those diagnostics already occur on trunk, but before this patch they would not break the test, as they were ignored by the VerifyDiagnosticConsumer. This patch thus changes the module maps that have been recently introduced which broke the invariant of compatible modules maps in test/Modules/Inputs. llvm-svn: 193314
2013-10-24 15:51:24 +08:00
Lexer L(ID, SourceMgr.getBuffer(ID), SourceMgr, MMapLangOpts);
[modules] When building a dependency file, include module maps parsed in the current compilation, not just those from imported modules. llvm-svn: 244413
2015-08-09 12:46:57 +08:00
SourceLocation Start = L.getSourceLocation();
Allow multiple modules with the same name to coexist in the module cache To differentiate between two modules with the same name, we will consider the path the module map file that they are defined by* part of the ‘key’ for looking up the precompiled module (pcm file). Specifically, this patch renames the precompiled module (pcm) files from cache-path/<module hash>/Foo.pcm to cache-path/<module hash>/Foo-<hash of module map path>.pcm In addition, I’ve taught the ASTReader to re-resolve the names of imported modules during module loading so that if the header search context changes between when a module was originally built and when it is loaded we can rebuild it if necessary. For example, if module A imports module B first time: clang -I /path/to/A -I /path/to/B ... second time: clang -I /path/to/A -I /different/path/to/B ... will now rebuild A as expected. * in the case of inferred modules, we use the module map file that allowed the inference, not the __inferred_module.map file, since the inferred file path is the same for every inferred module. llvm-svn: 206201
2014-04-15 02:00:01 +08:00
ModuleMapParser Parser(L, SourceMgr, Target, Diags, *this, File, Dir,
[Modules] If a module map resides in a system header directory, treat it as a system module. This prevents -pedantic from causing warnings in the system headers used to create modules. Fixes <rdar://problem/14201171>. llvm-svn: 184560
2013-06-22 00:28:10 +08:00
BuiltinIncludeDir, IsSystem);
Introduce basic support for parsing module map files. Module map files provide a way to map between headers and modules, so that we can layer a module system on top of existing headers without changing those headers at all. This commit introduces the module map file parser and the module map that it generates, and wires up the module map file parser so that we'll automatically find module map files as part of header search. Note that we don't yet use the information stored in the module map. llvm-svn: 144402
2011-11-12 03:10:28 +08:00
bool Result = Parser.parseModuleMapFile();
Rework the realpath nonsense for framework lookups to deal more uniformly with symlinks between top-level and embedded frameworks. llvm-svn: 172030
2013-01-10 09:43:00 +08:00
ParsedModuleMap[File] = Result;
[modules] When building a dependency file, include module maps parsed in the current compilation, not just those from imported modules. llvm-svn: 244413
2015-08-09 12:46:57 +08:00
// Notify callbacks that we parsed it.
for (const auto &Cb : Callbacks)
Cb->moduleMapFileRead(Start, *File, IsSystem);
Introduce basic support for parsing module map files. Module map files provide a way to map between headers and modules, so that we can layer a module system on top of existing headers without changing those headers at all. This commit introduces the module map file parser and the module map that it generates, and wires up the module map file parser so that we'll automatically find module map files as part of header search. Note that we don't yet use the information stored in the module map. llvm-svn: 144402
2011-11-12 03:10:28 +08:00
return Result;
}