llvm-project/clang/lib/Frontend/ModuleDependencyCollector.cpp

262 lines
9.6 KiB
C++
Raw Normal View History

//===--- ModuleDependencyCollector.cpp - Collect module dependencies ------===//
//
// The LLVM Compiler Infrastructure
//
// This file is distributed under the University of Illinois Open Source
// License. See LICENSE.TXT for details.
//
//===----------------------------------------------------------------------===//
//
// Collect the dependencies of a set of modules.
//
//===----------------------------------------------------------------------===//
#include "clang/Basic/CharInfo.h"
#include "clang/Frontend/Utils.h"
[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
#include "clang/Lex/Preprocessor.h"
#include "clang/Serialization/ASTReader.h"
#include "llvm/ADT/iterator_range.h"
2014-06-20 03:49:28 +08:00
#include "llvm/Support/FileSystem.h"
#include "llvm/Support/Path.h"
#include "llvm/Support/raw_ostream.h"
using namespace clang;
namespace {
[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
/// Private implementations for ModuleDependencyCollector
class ModuleDependencyListener : public ASTReaderListener {
ModuleDependencyCollector &Collector;
public:
ModuleDependencyListener(ModuleDependencyCollector &Collector)
: Collector(Collector) {}
bool needsInputFileVisitation() override { return true; }
bool needsSystemInputFileVisitation() override { return true; }
bool visitInputFile(StringRef Filename, bool IsSystem, bool IsOverridden,
bool IsExplicitModule) override {
Collector.addFile(Filename);
return true;
}
};
[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
struct ModuleDependencyPPCallbacks : public PPCallbacks {
ModuleDependencyCollector &Collector;
SourceManager &SM;
ModuleDependencyPPCallbacks(ModuleDependencyCollector &Collector,
SourceManager &SM)
: Collector(Collector), SM(SM) {}
void InclusionDirective(SourceLocation HashLoc, const Token &IncludeTok,
StringRef FileName, bool IsAngled,
CharSourceRange FilenameRange, const FileEntry *File,
StringRef SearchPath, StringRef RelativePath,
const Module *Imported) override {
if (!File)
return;
Collector.addFile(File->getName());
}
};
[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
struct ModuleDependencyMMCallbacks : public ModuleMapCallbacks {
ModuleDependencyCollector &Collector;
ModuleDependencyMMCallbacks(ModuleDependencyCollector &Collector)
: Collector(Collector) {}
void moduleMapAddHeader(StringRef HeaderPath) override {
[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
if (llvm::sys::path::is_absolute(HeaderPath))
Collector.addFile(HeaderPath);
}
[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
void moduleMapAddUmbrellaHeader(FileManager *FileMgr,
const FileEntry *Header) override {
StringRef HeaderFilename = Header->getName();
moduleMapAddHeader(HeaderFilename);
// The FileManager can find and cache the symbolic link for a framework
// header before its real path, this means a module can have some of its
// headers to use other paths. Although this is usually not a problem, it's
// inconsistent, and not collecting the original path header leads to
// umbrella clashes while rebuilding modules in the crash reproducer. For
// example:
// ApplicationServices.framework/Frameworks/ImageIO.framework/ImageIO.h
// instead of:
// ImageIO.framework/ImageIO.h
//
// FIXME: this shouldn't be necessary once we have FileName instances
// around instead of FileEntry ones. For now, make sure we collect all
// that we need for the reproducer to work correctly.
StringRef UmbreallDirFromHeader =
llvm::sys::path::parent_path(HeaderFilename);
StringRef UmbrellaDir = Header->getDir()->getName();
if (!UmbrellaDir.equals(UmbreallDirFromHeader)) {
SmallString<128> AltHeaderFilename;
llvm::sys::path::append(AltHeaderFilename, UmbrellaDir,
llvm::sys::path::filename(HeaderFilename));
if (FileMgr->getFile(AltHeaderFilename))
moduleMapAddHeader(AltHeaderFilename);
}
}
[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
};
}
// TODO: move this to Support/Path.h and check for HAVE_REALPATH?
static bool real_path(StringRef SrcPath, SmallVectorImpl<char> &RealPath) {
#ifdef LLVM_ON_UNIX
char CanonicalPath[PATH_MAX];
// TODO: emit a warning in case this fails...?
if (!realpath(SrcPath.str().c_str(), CanonicalPath))
return false;
SmallString<256> RPath(CanonicalPath);
RealPath.swap(RPath);
return true;
#else
// FIXME: Add support for systems without realpath.
return false;
#endif
}
void ModuleDependencyCollector::attachToASTReader(ASTReader &R) {
R.addListener(llvm::make_unique<ModuleDependencyListener>(*this));
}
[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
void ModuleDependencyCollector::attachToPreprocessor(Preprocessor &PP) {
PP.addPPCallbacks(llvm::make_unique<ModuleDependencyPPCallbacks>(
*this, PP.getSourceManager()));
[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
PP.getHeaderSearchInfo().getModuleMap().addModuleMapCallbacks(
llvm::make_unique<ModuleDependencyMMCallbacks>(*this));
}
static bool isCaseSensitivePath(StringRef Path) {
SmallString<256> TmpDest = Path, UpperDest, RealDest;
// Remove component traversals, links, etc.
if (!real_path(Path, TmpDest))
return true; // Current default value in vfs.yaml
Path = TmpDest;
// Change path to all upper case and ask for its real path, if the latter
// exists and is equal to Path, it's not case sensitive. Default to case
// sensitive in the absense of realpath, since this is what the VFSWriter
// already expects when sensitivity isn't setup.
for (auto &C : Path)
UpperDest.push_back(toUppercase(C));
if (real_path(UpperDest, RealDest) && Path.equals(RealDest))
return false;
return true;
}
void ModuleDependencyCollector::writeFileMap() {
if (Seen.empty())
return;
StringRef VFSDir = getDest();
Reapply [2] [VFS] Add 'overlay-relative' field to YAML files This reapplies r261552 and r263748. Fixed testcase to reapply. The VFS overlay mapping between virtual paths and real paths is done through the 'external-contents' entries in YAML files, which contains hardcoded paths to the real files. When a module compilation crashes, headers are dumped into <name>.cache/vfs directory and are mapped via the <name>.cache/vfs/vfs.yaml. The script generated for reproduction uses -ivfsoverlay pointing to file to gather the mapping between virtual paths and files inside <name>.cache/vfs. Currently, we are only capable of reproducing such crashes in the same machine as they happen, because of the hardcoded paths in 'external-contents'. To be able to reproduce a crash in another machine, this patch introduces a new option in the VFS yaml file called 'overlay-relative'. When it's equal to 'true' it means that the provided path to the YAML file through the -ivfsoverlay option should also be used to prefix the final path for every 'external-contents'. Example, given the invocation snippet "... -ivfsoverlay <name>.cache/vfs/vfs.yaml" and the following entry in the yaml file: "overlay-relative": "true", "roots": [ ... "type": "directory", "name": "/usr/include", "contents": [ { "type": "file", "name": "stdio.h", "external-contents": "/usr/include/stdio.h" }, ... Here, a file manager request for virtual "/usr/include/stdio.h", that will map into real path "/<absolute_path_to>/<name>.cache/vfs/usr/include/stdio.h. This is a useful feature for debugging module crashes in machines other than the one where the error happened. Differential Revision: http://reviews.llvm.org/D17457 rdar://problem/24499339 llvm-svn: 263893
2016-03-20 10:08:48 +08:00
// Default to use relative overlay directories in the VFS yaml file. This
// allows crash reproducer scripts to work across machines.
VFSWriter.setOverlayDir(VFSDir);
// Do not ignore non existent contents otherwise we might skip something
// that should have been collected here.
VFSWriter.setIgnoreNonExistentContents(false);
// Explicitly set case sensitivity for the YAML writer. For that, find out
// the sensitivity at the path where the headers all collected to.
VFSWriter.setCaseSensitivity(isCaseSensitivePath(VFSDir));
Reapply [2] [VFS] Add 'overlay-relative' field to YAML files This reapplies r261552 and r263748. Fixed testcase to reapply. The VFS overlay mapping between virtual paths and real paths is done through the 'external-contents' entries in YAML files, which contains hardcoded paths to the real files. When a module compilation crashes, headers are dumped into <name>.cache/vfs directory and are mapped via the <name>.cache/vfs/vfs.yaml. The script generated for reproduction uses -ivfsoverlay pointing to file to gather the mapping between virtual paths and files inside <name>.cache/vfs. Currently, we are only capable of reproducing such crashes in the same machine as they happen, because of the hardcoded paths in 'external-contents'. To be able to reproduce a crash in another machine, this patch introduces a new option in the VFS yaml file called 'overlay-relative'. When it's equal to 'true' it means that the provided path to the YAML file through the -ivfsoverlay option should also be used to prefix the final path for every 'external-contents'. Example, given the invocation snippet "... -ivfsoverlay <name>.cache/vfs/vfs.yaml" and the following entry in the yaml file: "overlay-relative": "true", "roots": [ ... "type": "directory", "name": "/usr/include", "contents": [ { "type": "file", "name": "stdio.h", "external-contents": "/usr/include/stdio.h" }, ... Here, a file manager request for virtual "/usr/include/stdio.h", that will map into real path "/<absolute_path_to>/<name>.cache/vfs/usr/include/stdio.h. This is a useful feature for debugging module crashes in machines other than the one where the error happened. Differential Revision: http://reviews.llvm.org/D17457 rdar://problem/24499339 llvm-svn: 263893
2016-03-20 10:08:48 +08:00
// Do not rely on real path names when executing the crash reproducer scripts
// since we only want to actually use the files we have on the VFS cache.
VFSWriter.setUseExternalNames(false);
std::error_code EC;
SmallString<256> YAMLPath = VFSDir;
llvm::sys::path::append(YAMLPath, "vfs.yaml");
llvm::raw_fd_ostream OS(YAMLPath, EC, llvm::sys::fs::F_Text);
if (EC) {
HasErrors = true;
return;
}
VFSWriter.write(OS);
}
bool ModuleDependencyCollector::getRealPath(StringRef SrcPath,
SmallVectorImpl<char> &Result) {
using namespace llvm::sys;
SmallString<256> RealPath;
StringRef FileName = path::filename(SrcPath);
std::string Dir = path::parent_path(SrcPath).str();
auto DirWithSymLink = SymLinkMap.find(Dir);
// Use real_path to fix any symbolic link component present in a path.
// Computing the real path is expensive, cache the search through the
// parent path directory.
if (DirWithSymLink == SymLinkMap.end()) {
if (!real_path(Dir, RealPath))
return false;
SymLinkMap[Dir] = RealPath.str();
} else {
RealPath = DirWithSymLink->second;
}
path::append(RealPath, FileName);
Result.swap(RealPath);
return true;
}
std::error_code ModuleDependencyCollector::copyToRoot(StringRef Src,
StringRef Dst) {
using namespace llvm::sys;
// We need an absolute src path to append to the root.
SmallString<256> AbsoluteSrc = Src;
fs::make_absolute(AbsoluteSrc);
// Canonicalize src to a native path to avoid mixed separator styles.
path::native(AbsoluteSrc);
// Remove redundant leading "./" pieces and consecutive separators.
AbsoluteSrc = path::remove_leading_dotslash(AbsoluteSrc);
// Canonicalize the source path by removing "..", "." components.
SmallString<256> VirtualPath = AbsoluteSrc;
path::remove_dots(VirtualPath, /*remove_dot_dot=*/true);
// If a ".." component is present after a symlink component, remove_dots may
// lead to the wrong real destination path. Let the source be canonicalized
// like that but make sure we always use the real path for the destination.
SmallString<256> CopyFrom;
if (!getRealPath(AbsoluteSrc, CopyFrom))
CopyFrom = VirtualPath;
SmallString<256> CacheDst = getDest();
if (Dst.empty()) {
// The common case is to map the virtual path to the same path inside the
// cache.
path::append(CacheDst, path::relative_path(CopyFrom));
} else {
// When collecting entries from input vfsoverlays, copy the external
// contents into the cache but still map from the source.
if (!fs::exists(Dst))
return std::error_code();
path::append(CacheDst, Dst);
CopyFrom = Dst;
}
// Copy the file into place.
if (std::error_code EC = fs::create_directories(path::parent_path(CacheDst),
/*IgnoreExisting=*/true))
return EC;
if (std::error_code EC = fs::copy_file(CopyFrom, CacheDst))
return EC;
// Always map a canonical src path to its real path into the YAML, by doing
// this we map different virtual src paths to the same entry in the VFS
// overlay, which is a way to emulate symlink inside the VFS; this is also
// needed for correctness, not doing that can lead to module redefinition
// errors.
addFileMapping(VirtualPath, CacheDst);
return std::error_code();
}
void ModuleDependencyCollector::addFile(StringRef Filename, StringRef FileDst) {
if (insertSeen(Filename))
if (copyToRoot(Filename, FileDst))
HasErrors = true;
}