2010-11-24 03:19:34 +08:00
|
|
|
//===--- FileManager.cpp - File System Probing and Caching ----------------===//
|
2006-06-18 13:43:12 +08:00
|
|
|
//
|
2019-01-19 16:50:56 +08:00
|
|
|
// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
|
|
|
|
// See https://llvm.org/LICENSE.txt for license information.
|
|
|
|
// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
|
2006-06-18 13:43:12 +08:00
|
|
|
//
|
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
//
|
|
|
|
// This file implements the FileManager interface.
|
|
|
|
//
|
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
//
|
|
|
|
// TODO: This should index all interesting directories with dirent calls.
|
|
|
|
// getdirentries ?
|
|
|
|
// opendir/readdir_r/closedir ?
|
|
|
|
//
|
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
|
|
|
|
#include "clang/Basic/FileManager.h"
|
2010-11-24 03:19:34 +08:00
|
|
|
#include "clang/Basic/FileSystemStatCache.h"
|
2019-10-12 02:22:34 +08:00
|
|
|
#include "llvm/ADT/STLExtras.h"
|
2006-10-30 11:55:17 +08:00
|
|
|
#include "llvm/ADT/SmallString.h"
|
2019-10-12 02:22:34 +08:00
|
|
|
#include "llvm/ADT/Statistic.h"
|
2012-12-04 17:13:33 +08:00
|
|
|
#include "llvm/Config/llvm-config.h"
|
2010-12-22 00:45:57 +08:00
|
|
|
#include "llvm/Support/FileSystem.h"
|
2010-11-04 06:45:23 +08:00
|
|
|
#include "llvm/Support/MemoryBuffer.h"
|
2010-11-30 02:12:39 +08:00
|
|
|
#include "llvm/Support/Path.h"
|
2012-12-04 17:13:33 +08:00
|
|
|
#include "llvm/Support/raw_ostream.h"
|
2016-08-13 09:05:35 +08:00
|
|
|
#include <algorithm>
|
|
|
|
#include <cassert>
|
|
|
|
#include <climits>
|
|
|
|
#include <cstdint>
|
|
|
|
#include <cstdlib>
|
2009-09-05 17:49:39 +08:00
|
|
|
#include <string>
|
2016-08-13 09:05:35 +08:00
|
|
|
#include <utility>
|
2010-11-24 05:53:15 +08:00
|
|
|
|
2006-06-18 13:43:12 +08:00
|
|
|
using namespace clang;
|
|
|
|
|
2019-10-12 02:22:34 +08:00
|
|
|
#define DEBUG_TYPE "file-search"
|
|
|
|
|
|
|
|
ALWAYS_ENABLED_STATISTIC(NumDirLookups, "Number of directory lookups.");
|
|
|
|
ALWAYS_ENABLED_STATISTIC(NumFileLookups, "Number of file lookups.");
|
|
|
|
ALWAYS_ENABLED_STATISTIC(NumDirCacheMisses,
|
|
|
|
"Number of directory cache misses.");
|
|
|
|
ALWAYS_ENABLED_STATISTIC(NumFileCacheMisses, "Number of file cache misses.");
|
|
|
|
|
2009-01-28 08:27:31 +08:00
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
// Common logic.
|
|
|
|
//===----------------------------------------------------------------------===//
|
2008-02-24 11:15:25 +08:00
|
|
|
|
2014-02-21 05:59:23 +08:00
|
|
|
FileManager::FileManager(const FileSystemOptions &FSO,
|
2018-10-10 21:27:25 +08:00
|
|
|
IntrusiveRefCntPtr<llvm::vfs::FileSystem> FS)
|
2017-03-22 05:35:04 +08:00
|
|
|
: FS(std::move(FS)), FileSystemOpts(FSO), SeenDirEntries(64),
|
|
|
|
SeenFileEntries(64), NextFileUID(0) {
|
2014-02-21 05:59:23 +08:00
|
|
|
// If the caller doesn't provide a virtual file system, just grab the real
|
|
|
|
// file system.
|
2017-03-22 05:35:04 +08:00
|
|
|
if (!this->FS)
|
2018-10-10 21:27:25 +08:00
|
|
|
this->FS = llvm::vfs::getRealFileSystem();
|
2008-02-24 11:15:25 +08:00
|
|
|
}
|
|
|
|
|
2015-12-10 01:23:13 +08:00
|
|
|
FileManager::~FileManager() = default;
|
2008-02-24 11:15:25 +08:00
|
|
|
|
2018-12-22 03:33:09 +08:00
|
|
|
void FileManager::setStatCache(std::unique_ptr<FileSystemStatCache> statCache) {
|
2009-10-17 02:18:30 +08:00
|
|
|
assert(statCache && "No stat cache provided?");
|
2018-12-22 03:33:09 +08:00
|
|
|
StatCache = std::move(statCache);
|
2009-10-17 02:18:30 +08:00
|
|
|
}
|
|
|
|
|
2018-12-22 03:33:09 +08:00
|
|
|
void FileManager::clearStatCache() { StatCache.reset(); }
|
2012-07-31 21:56:54 +08:00
|
|
|
|
2018-05-09 09:00:01 +08:00
|
|
|
/// Retrieve the directory that the given file name resides in.
|
2011-02-12 02:44:49 +08:00
|
|
|
/// Filename can point to either a real file or a virtual file.
|
2019-08-02 05:31:49 +08:00
|
|
|
static llvm::ErrorOr<const DirectoryEntry *>
|
|
|
|
getDirectoryFromFile(FileManager &FileMgr, StringRef Filename,
|
|
|
|
bool CacheFailure) {
|
2011-02-12 05:25:35 +08:00
|
|
|
if (Filename.empty())
|
2019-08-02 05:31:49 +08:00
|
|
|
return std::errc::no_such_file_or_directory;
|
2011-02-12 02:44:49 +08:00
|
|
|
|
2011-02-12 05:25:35 +08:00
|
|
|
if (llvm::sys::path::is_separator(Filename[Filename.size() - 1]))
|
2019-08-02 05:31:49 +08:00
|
|
|
return std::errc::is_a_directory;
|
2010-11-21 19:32:22 +08:00
|
|
|
|
2011-07-23 18:55:15 +08:00
|
|
|
StringRef DirName = llvm::sys::path::parent_path(Filename);
|
2010-11-21 17:50:16 +08:00
|
|
|
// Use the current directory if file has no path component.
|
2011-02-12 05:25:35 +08:00
|
|
|
if (DirName.empty())
|
|
|
|
DirName = ".";
|
2010-11-21 19:32:22 +08:00
|
|
|
|
2011-09-14 07:15:45 +08:00
|
|
|
return FileMgr.getDirectory(DirName, CacheFailure);
|
2009-12-03 02:12:28 +08:00
|
|
|
}
|
|
|
|
|
2011-02-12 02:44:49 +08:00
|
|
|
/// Add all ancestors of the given path (pointing to either a file or
|
|
|
|
/// a directory) as virtual directories.
|
2011-07-23 18:55:15 +08:00
|
|
|
void FileManager::addAncestorsAsVirtualDirs(StringRef Path) {
|
|
|
|
StringRef DirName = llvm::sys::path::parent_path(Path);
|
2011-02-12 05:25:35 +08:00
|
|
|
if (DirName.empty())
|
2016-04-13 00:33:53 +08:00
|
|
|
DirName = ".";
|
2011-02-12 02:44:49 +08:00
|
|
|
|
2019-08-02 05:31:49 +08:00
|
|
|
auto &NamedDirEnt = *SeenDirEntries.insert(
|
|
|
|
{DirName, std::errc::no_such_file_or_directory}).first;
|
2011-02-12 02:44:49 +08:00
|
|
|
|
|
|
|
// When caching a virtual directory, we always cache its ancestors
|
|
|
|
// at the same time. Therefore, if DirName is already in the cache,
|
|
|
|
// we don't need to recurse as its ancestors must also already be in
|
2019-01-30 10:23:34 +08:00
|
|
|
// the cache (or it's a known non-virtual directory).
|
|
|
|
if (NamedDirEnt.second)
|
2011-02-12 02:44:49 +08:00
|
|
|
return;
|
|
|
|
|
|
|
|
// Add the virtual directory to the cache.
|
2019-08-15 07:04:18 +08:00
|
|
|
auto UDE = std::make_unique<DirectoryEntry>();
|
2016-10-11 15:31:29 +08:00
|
|
|
UDE->Name = NamedDirEnt.first();
|
2019-08-02 05:31:49 +08:00
|
|
|
NamedDirEnt.second = *UDE.get();
|
2015-12-10 01:23:13 +08:00
|
|
|
VirtualDirectoryEntries.push_back(std::move(UDE));
|
2011-02-12 02:44:49 +08:00
|
|
|
|
|
|
|
// Recursively add the other ancestors.
|
|
|
|
addAncestorsAsVirtualDirs(DirName);
|
|
|
|
}
|
|
|
|
|
2019-08-31 09:26:04 +08:00
|
|
|
llvm::Expected<DirectoryEntryRef>
|
|
|
|
FileManager::getDirectoryRef(StringRef DirName, bool CacheFailure) {
|
2012-06-16 14:04:10 +08:00
|
|
|
// stat doesn't like trailing separators except for root directory.
|
2011-11-17 14:16:05 +08:00
|
|
|
// At least, on Win32 MSVCRT, stat() cannot strip trailing '/'.
|
|
|
|
// (though it can strip '\\')
|
2012-06-16 14:04:10 +08:00
|
|
|
if (DirName.size() > 1 &&
|
|
|
|
DirName != llvm::sys::path::root_path(DirName) &&
|
|
|
|
llvm::sys::path::is_separator(DirName.back()))
|
2011-11-17 14:16:05 +08:00
|
|
|
DirName = DirName.substr(0, DirName.size()-1);
|
2018-04-28 03:11:14 +08:00
|
|
|
#ifdef _WIN32
|
2013-07-29 23:47:24 +08:00
|
|
|
// Fixing a problem with "clang C:test.c" on Windows.
|
|
|
|
// Stat("C:") does not recognize "C:" as a valid directory
|
|
|
|
std::string DirNameStr;
|
|
|
|
if (DirName.size() > 1 && DirName.back() == ':' &&
|
|
|
|
DirName.equals_lower(llvm::sys::path::root_name(DirName))) {
|
|
|
|
DirNameStr = DirName.str() + '.';
|
|
|
|
DirName = DirNameStr;
|
|
|
|
}
|
|
|
|
#endif
|
2011-11-17 14:16:05 +08:00
|
|
|
|
2006-06-18 13:43:12 +08:00
|
|
|
++NumDirLookups;
|
2009-09-09 23:08:12 +08:00
|
|
|
|
2011-02-12 02:44:49 +08:00
|
|
|
// See if there was already an entry in the map. Note that the map
|
|
|
|
// contains both virtual and real directories.
|
2019-08-02 05:31:49 +08:00
|
|
|
auto SeenDirInsertResult =
|
|
|
|
SeenDirEntries.insert({DirName, std::errc::no_such_file_or_directory});
|
2019-08-31 09:26:04 +08:00
|
|
|
if (!SeenDirInsertResult.second) {
|
|
|
|
if (SeenDirInsertResult.first->second)
|
|
|
|
return DirectoryEntryRef(&*SeenDirInsertResult.first);
|
|
|
|
return llvm::errorCodeToError(SeenDirInsertResult.first->second.getError());
|
|
|
|
}
|
2009-09-09 23:08:12 +08:00
|
|
|
|
2019-01-30 10:23:34 +08:00
|
|
|
// We've not seen this before. Fill it in.
|
2006-06-18 13:43:12 +08:00
|
|
|
++NumDirCacheMisses;
|
2019-01-30 10:23:34 +08:00
|
|
|
auto &NamedDirEnt = *SeenDirInsertResult.first;
|
|
|
|
assert(!NamedDirEnt.second && "should be newly-created");
|
2009-09-09 23:08:12 +08:00
|
|
|
|
2006-10-30 11:40:58 +08:00
|
|
|
// Get the null-terminated directory name as stored as the key of the
|
2011-02-12 02:44:49 +08:00
|
|
|
// SeenDirEntries map.
|
2016-10-11 15:31:29 +08:00
|
|
|
StringRef InterndDirName = NamedDirEnt.first();
|
2009-09-09 23:08:12 +08:00
|
|
|
|
2006-10-30 11:06:54 +08:00
|
|
|
// Check to see if the directory exists.
|
2019-03-05 10:27:12 +08:00
|
|
|
llvm::vfs::Status Status;
|
2019-08-02 05:31:49 +08:00
|
|
|
auto statError = getStatValue(InterndDirName, Status, false,
|
|
|
|
nullptr /*directory lookup*/);
|
|
|
|
if (statError) {
|
2011-02-12 02:44:49 +08:00
|
|
|
// There's no real directory at the given path.
|
2019-08-02 05:31:49 +08:00
|
|
|
if (CacheFailure)
|
|
|
|
NamedDirEnt.second = statError;
|
|
|
|
else
|
2011-09-14 07:15:45 +08:00
|
|
|
SeenDirEntries.erase(DirName);
|
2019-08-31 09:26:04 +08:00
|
|
|
return llvm::errorCodeToError(statError);
|
2011-02-12 02:44:49 +08:00
|
|
|
}
|
2008-02-24 11:15:25 +08:00
|
|
|
|
2011-02-12 02:44:49 +08:00
|
|
|
// It exists. See if we have already opened a directory with the
|
|
|
|
// same inode (this occurs on Unix-like systems when one dir is
|
|
|
|
// symlinked to another, for example) or the same path (on
|
|
|
|
// Windows).
|
2019-03-05 10:27:12 +08:00
|
|
|
DirectoryEntry &UDE = UniqueRealDirs[Status.getUniqueID()];
|
2009-09-09 23:08:12 +08:00
|
|
|
|
2019-08-02 05:31:49 +08:00
|
|
|
NamedDirEnt.second = UDE;
|
2016-10-11 15:31:29 +08:00
|
|
|
if (UDE.getName().empty()) {
|
2011-02-12 02:44:49 +08:00
|
|
|
// We don't have this directory yet, add it. We use the string
|
|
|
|
// key from the SeenDirEntries map as the string.
|
|
|
|
UDE.Name = InterndDirName;
|
|
|
|
}
|
2009-09-09 23:08:12 +08:00
|
|
|
|
2019-08-31 09:26:04 +08:00
|
|
|
return DirectoryEntryRef(&NamedDirEnt);
|
|
|
|
}
|
|
|
|
|
|
|
|
llvm::ErrorOr<const DirectoryEntry *>
|
|
|
|
FileManager::getDirectory(StringRef DirName, bool CacheFailure) {
|
|
|
|
auto Result = getDirectoryRef(DirName, CacheFailure);
|
|
|
|
if (Result)
|
|
|
|
return &Result->getDirEntry();
|
|
|
|
return llvm::errorToErrorCode(Result.takeError());
|
2006-06-18 13:43:12 +08:00
|
|
|
}
|
|
|
|
|
2019-08-02 05:31:49 +08:00
|
|
|
llvm::ErrorOr<const FileEntry *>
|
|
|
|
FileManager::getFile(StringRef Filename, bool openFile, bool CacheFailure) {
|
Introduce FileEntryRef and use it when handling includes to report correct dependencies
when the FileManager is reused across invocations
This commit introduces a parallel API to FileManager's getFile: getFileEntryRef, which returns
a reference to the FileEntry, and the name that was used to access the file. In the case of
a VFS with 'use-external-names', the FileEntyRef contains the external name of the file,
not the filename that was used to access it.
The new API is adopted only in the HeaderSearch and Preprocessor for include file lookup, so that the
accessed path can be propagated to SourceManager's FileInfo. SourceManager's FileInfo now can report this accessed path, using
the new getName method. This API is then adopted in the dependency collector, which now correctly reports dependencies when a file
is included both using a symlink and a real path in the case when the FileManager is reused across multiple Preprocessor invocations.
Note that this patch does not fix all dependency collector issues, as the same problem is still present in other cases when dependencies
are obtained using FileSkipped, InclusionDirective, and HasInclude. This will be fixed in follow-up commits.
Differential Revision: https://reviews.llvm.org/D65907
llvm-svn: 369680
2019-08-23 02:15:50 +08:00
|
|
|
auto Result = getFileRef(Filename, openFile, CacheFailure);
|
|
|
|
if (Result)
|
|
|
|
return &Result->getFileEntry();
|
2019-08-27 02:29:51 +08:00
|
|
|
return llvm::errorToErrorCode(Result.takeError());
|
Introduce FileEntryRef and use it when handling includes to report correct dependencies
when the FileManager is reused across invocations
This commit introduces a parallel API to FileManager's getFile: getFileEntryRef, which returns
a reference to the FileEntry, and the name that was used to access the file. In the case of
a VFS with 'use-external-names', the FileEntyRef contains the external name of the file,
not the filename that was used to access it.
The new API is adopted only in the HeaderSearch and Preprocessor for include file lookup, so that the
accessed path can be propagated to SourceManager's FileInfo. SourceManager's FileInfo now can report this accessed path, using
the new getName method. This API is then adopted in the dependency collector, which now correctly reports dependencies when a file
is included both using a symlink and a real path in the case when the FileManager is reused across multiple Preprocessor invocations.
Note that this patch does not fix all dependency collector issues, as the same problem is still present in other cases when dependencies
are obtained using FileSkipped, InclusionDirective, and HasInclude. This will be fixed in follow-up commits.
Differential Revision: https://reviews.llvm.org/D65907
llvm-svn: 369680
2019-08-23 02:15:50 +08:00
|
|
|
}
|
|
|
|
|
2019-08-27 02:29:51 +08:00
|
|
|
llvm::Expected<FileEntryRef>
|
Introduce FileEntryRef and use it when handling includes to report correct dependencies
when the FileManager is reused across invocations
This commit introduces a parallel API to FileManager's getFile: getFileEntryRef, which returns
a reference to the FileEntry, and the name that was used to access the file. In the case of
a VFS with 'use-external-names', the FileEntyRef contains the external name of the file,
not the filename that was used to access it.
The new API is adopted only in the HeaderSearch and Preprocessor for include file lookup, so that the
accessed path can be propagated to SourceManager's FileInfo. SourceManager's FileInfo now can report this accessed path, using
the new getName method. This API is then adopted in the dependency collector, which now correctly reports dependencies when a file
is included both using a symlink and a real path in the case when the FileManager is reused across multiple Preprocessor invocations.
Note that this patch does not fix all dependency collector issues, as the same problem is still present in other cases when dependencies
are obtained using FileSkipped, InclusionDirective, and HasInclude. This will be fixed in follow-up commits.
Differential Revision: https://reviews.llvm.org/D65907
llvm-svn: 369680
2019-08-23 02:15:50 +08:00
|
|
|
FileManager::getFileRef(StringRef Filename, bool openFile, bool CacheFailure) {
|
2006-06-18 13:43:12 +08:00
|
|
|
++NumFileLookups;
|
2009-09-09 23:08:12 +08:00
|
|
|
|
2006-06-18 13:43:12 +08:00
|
|
|
// See if there is already an entry in the map.
|
2019-08-02 05:31:49 +08:00
|
|
|
auto SeenFileInsertResult =
|
|
|
|
SeenFileEntries.insert({Filename, std::errc::no_such_file_or_directory});
|
Introduce FileEntryRef and use it when handling includes to report correct dependencies
when the FileManager is reused across invocations
This commit introduces a parallel API to FileManager's getFile: getFileEntryRef, which returns
a reference to the FileEntry, and the name that was used to access the file. In the case of
a VFS with 'use-external-names', the FileEntyRef contains the external name of the file,
not the filename that was used to access it.
The new API is adopted only in the HeaderSearch and Preprocessor for include file lookup, so that the
accessed path can be propagated to SourceManager's FileInfo. SourceManager's FileInfo now can report this accessed path, using
the new getName method. This API is then adopted in the dependency collector, which now correctly reports dependencies when a file
is included both using a symlink and a real path in the case when the FileManager is reused across multiple Preprocessor invocations.
Note that this patch does not fix all dependency collector issues, as the same problem is still present in other cases when dependencies
are obtained using FileSkipped, InclusionDirective, and HasInclude. This will be fixed in follow-up commits.
Differential Revision: https://reviews.llvm.org/D65907
llvm-svn: 369680
2019-08-23 02:15:50 +08:00
|
|
|
if (!SeenFileInsertResult.second) {
|
|
|
|
if (!SeenFileInsertResult.first->second)
|
2019-08-27 02:29:51 +08:00
|
|
|
return llvm::errorCodeToError(
|
|
|
|
SeenFileInsertResult.first->second.getError());
|
Introduce FileEntryRef and use it when handling includes to report correct dependencies
when the FileManager is reused across invocations
This commit introduces a parallel API to FileManager's getFile: getFileEntryRef, which returns
a reference to the FileEntry, and the name that was used to access the file. In the case of
a VFS with 'use-external-names', the FileEntyRef contains the external name of the file,
not the filename that was used to access it.
The new API is adopted only in the HeaderSearch and Preprocessor for include file lookup, so that the
accessed path can be propagated to SourceManager's FileInfo. SourceManager's FileInfo now can report this accessed path, using
the new getName method. This API is then adopted in the dependency collector, which now correctly reports dependencies when a file
is included both using a symlink and a real path in the case when the FileManager is reused across multiple Preprocessor invocations.
Note that this patch does not fix all dependency collector issues, as the same problem is still present in other cases when dependencies
are obtained using FileSkipped, InclusionDirective, and HasInclude. This will be fixed in follow-up commits.
Differential Revision: https://reviews.llvm.org/D65907
llvm-svn: 369680
2019-08-23 02:15:50 +08:00
|
|
|
// Construct and return and FileEntryRef, unless it's a redirect to another
|
|
|
|
// filename.
|
|
|
|
SeenFileEntryOrRedirect Value = *SeenFileInsertResult.first->second;
|
|
|
|
FileEntry *FE;
|
|
|
|
if (LLVM_LIKELY(FE = Value.dyn_cast<FileEntry *>()))
|
|
|
|
return FileEntryRef(SeenFileInsertResult.first->first(), *FE);
|
|
|
|
return getFileRef(*Value.get<const StringRef *>(), openFile, CacheFailure);
|
|
|
|
}
|
2009-09-09 23:08:12 +08:00
|
|
|
|
2019-01-30 10:23:34 +08:00
|
|
|
// We've not seen this before. Fill it in.
|
2006-06-18 13:43:12 +08:00
|
|
|
++NumFileCacheMisses;
|
2019-11-09 05:37:13 +08:00
|
|
|
auto *NamedFileEnt = &*SeenFileInsertResult.first;
|
|
|
|
assert(!NamedFileEnt->second && "should be newly-created");
|
[FileManager] Revert r347205 to avoid PCH file-descriptor leak.
Summary:
r347205 fixed a bug in FileManager: first calling
getFile(shouldOpen=false) and then getFile(shouldOpen=true) results in
the file not being open.
Unfortunately, some code was (inadvertently?) relying on this bug: when
building with a PCH, the file entries are obtained first by passing
shouldOpen=false, and then later shouldOpen=true, without any intention
of reading them. After r347205, they do get unneccesarily opened.
Aside from extra operations, this means they need to be closed. Normally
files are closed when their contents are read. As these files are never
read, they stay open until clang exits. On platforms with a low
open-files limit (e.g. Mac), this can lead to spurious file-not-found
errors when building large projects with PCH enabled, e.g.
https://bugs.chromium.org/p/chromium/issues/detail?id=924225
Fixing the callsites to pass shouldOpen=false when the file won't be
read is not quite trivial (that info isn't available at the direct
callsite), and passing shouldOpen=false is a performance regression (it
results in open+fstat pairs being replaced by stat+open).
So an ideal fix is going to be a little risky and we need some fix soon
(especially for the llvm 8 branch).
The problem addressed by r347205 is rare and has only been observed in
clangd. It was present in llvm-7, so we can live with it for now.
Reviewers: bkramer, thakis
Subscribers: ilya-biryukov, ioeric, kadircet, cfe-commits
Differential Revision: https://reviews.llvm.org/D57165
llvm-svn: 352079
2019-01-25 02:55:24 +08:00
|
|
|
|
2006-10-30 11:55:17 +08:00
|
|
|
// Get the null-terminated file name as stored as the key of the
|
2011-02-12 02:44:49 +08:00
|
|
|
// SeenFileEntries map.
|
2019-11-09 05:37:13 +08:00
|
|
|
StringRef InterndFileName = NamedFileEnt->first();
|
2009-09-09 23:08:12 +08:00
|
|
|
|
2010-11-24 04:30:42 +08:00
|
|
|
// Look up the directory for the file. When looking up something like
|
|
|
|
// sys/foo.h we'll discover all of the search directories that have a 'sys'
|
|
|
|
// subdirectory. This will let us avoid having to waste time on known-to-fail
|
|
|
|
// searches when we go to find sys/bar.h, because all the search directories
|
|
|
|
// without a 'sys' subdir will get a cached failure result.
|
2019-08-02 05:31:49 +08:00
|
|
|
auto DirInfoOrErr = getDirectoryFromFile(*this, Filename, CacheFailure);
|
|
|
|
if (!DirInfoOrErr) { // Directory doesn't exist, file can't exist.
|
|
|
|
if (CacheFailure)
|
2019-11-09 05:37:13 +08:00
|
|
|
NamedFileEnt->second = DirInfoOrErr.getError();
|
2019-08-02 05:31:49 +08:00
|
|
|
else
|
2011-09-14 07:15:45 +08:00
|
|
|
SeenFileEntries.erase(Filename);
|
2014-05-08 14:41:40 +08:00
|
|
|
|
2019-08-27 02:29:51 +08:00
|
|
|
return llvm::errorCodeToError(DirInfoOrErr.getError());
|
2011-09-14 07:15:45 +08:00
|
|
|
}
|
2019-08-02 05:31:49 +08:00
|
|
|
const DirectoryEntry *DirInfo = *DirInfoOrErr;
|
2018-07-31 03:24:48 +08:00
|
|
|
|
2006-06-18 13:43:12 +08:00
|
|
|
// FIXME: Use the directory info to prune this, before doing the stat syscall.
|
|
|
|
// FIXME: This will reduce the # syscalls.
|
2009-09-09 23:08:12 +08:00
|
|
|
|
2019-01-30 10:23:34 +08:00
|
|
|
// Check to see if the file exists.
|
2018-10-10 21:27:25 +08:00
|
|
|
std::unique_ptr<llvm::vfs::File> F;
|
2019-03-05 10:27:12 +08:00
|
|
|
llvm::vfs::Status Status;
|
2019-08-02 05:31:49 +08:00
|
|
|
auto statError = getStatValue(InterndFileName, Status, true,
|
|
|
|
openFile ? &F : nullptr);
|
|
|
|
if (statError) {
|
2011-02-12 02:44:49 +08:00
|
|
|
// There's no real file at the given path.
|
2019-08-02 05:31:49 +08:00
|
|
|
if (CacheFailure)
|
2019-11-09 05:37:13 +08:00
|
|
|
NamedFileEnt->second = statError;
|
2019-08-02 05:31:49 +08:00
|
|
|
else
|
2011-09-14 07:15:45 +08:00
|
|
|
SeenFileEntries.erase(Filename);
|
2014-05-08 14:41:40 +08:00
|
|
|
|
2019-08-27 02:29:51 +08:00
|
|
|
return llvm::errorCodeToError(statError);
|
2011-02-12 02:44:49 +08:00
|
|
|
}
|
2009-09-09 23:08:12 +08:00
|
|
|
|
2014-02-21 15:23:53 +08:00
|
|
|
assert((openFile || !F) && "undesired open file");
|
2011-03-17 03:17:25 +08:00
|
|
|
|
2007-12-19 06:29:39 +08:00
|
|
|
// It exists. See if we have already opened a file with the same inode.
|
2006-06-18 13:43:12 +08:00
|
|
|
// This occurs when one dir is symlinked to another, for example.
|
2019-03-05 10:27:12 +08:00
|
|
|
FileEntry &UFE = UniqueRealFiles[Status.getUniqueID()];
|
2009-09-09 23:08:12 +08:00
|
|
|
|
2019-11-09 05:37:13 +08:00
|
|
|
NamedFileEnt->second = &UFE;
|
2014-09-09 00:15:54 +08:00
|
|
|
|
|
|
|
// If the name returned by getStatValue is different than Filename, re-intern
|
|
|
|
// the name.
|
2019-03-05 10:27:12 +08:00
|
|
|
if (Status.getName() != Filename) {
|
2019-08-27 01:31:06 +08:00
|
|
|
auto &NewNamedFileEnt =
|
Introduce FileEntryRef and use it when handling includes to report correct dependencies
when the FileManager is reused across invocations
This commit introduces a parallel API to FileManager's getFile: getFileEntryRef, which returns
a reference to the FileEntry, and the name that was used to access the file. In the case of
a VFS with 'use-external-names', the FileEntyRef contains the external name of the file,
not the filename that was used to access it.
The new API is adopted only in the HeaderSearch and Preprocessor for include file lookup, so that the
accessed path can be propagated to SourceManager's FileInfo. SourceManager's FileInfo now can report this accessed path, using
the new getName method. This API is then adopted in the dependency collector, which now correctly reports dependencies when a file
is included both using a symlink and a real path in the case when the FileManager is reused across multiple Preprocessor invocations.
Note that this patch does not fix all dependency collector issues, as the same problem is still present in other cases when dependencies
are obtained using FileSkipped, InclusionDirective, and HasInclude. This will be fixed in follow-up commits.
Differential Revision: https://reviews.llvm.org/D65907
llvm-svn: 369680
2019-08-23 02:15:50 +08:00
|
|
|
*SeenFileEntries.insert({Status.getName(), &UFE}).first;
|
2019-08-27 01:31:06 +08:00
|
|
|
assert((*NewNamedFileEnt.second).get<FileEntry *>() == &UFE &&
|
2019-01-30 10:23:34 +08:00
|
|
|
"filename from getStatValue() refers to wrong file");
|
2019-08-27 01:31:06 +08:00
|
|
|
InterndFileName = NewNamedFileEnt.first().data();
|
Introduce FileEntryRef and use it when handling includes to report correct dependencies
when the FileManager is reused across invocations
This commit introduces a parallel API to FileManager's getFile: getFileEntryRef, which returns
a reference to the FileEntry, and the name that was used to access the file. In the case of
a VFS with 'use-external-names', the FileEntyRef contains the external name of the file,
not the filename that was used to access it.
The new API is adopted only in the HeaderSearch and Preprocessor for include file lookup, so that the
accessed path can be propagated to SourceManager's FileInfo. SourceManager's FileInfo now can report this accessed path, using
the new getName method. This API is then adopted in the dependency collector, which now correctly reports dependencies when a file
is included both using a symlink and a real path in the case when the FileManager is reused across multiple Preprocessor invocations.
Note that this patch does not fix all dependency collector issues, as the same problem is still present in other cases when dependencies
are obtained using FileSkipped, InclusionDirective, and HasInclude. This will be fixed in follow-up commits.
Differential Revision: https://reviews.llvm.org/D65907
llvm-svn: 369680
2019-08-23 02:15:50 +08:00
|
|
|
// In addition to re-interning the name, construct a redirecting seen file
|
|
|
|
// entry, that will point to the name the filesystem actually wants to use.
|
|
|
|
StringRef *Redirect = new (CanonicalNameStorage) StringRef(InterndFileName);
|
2019-11-09 05:37:13 +08:00
|
|
|
auto SeenFileInsertResultIt = SeenFileEntries.find(Filename);
|
|
|
|
assert(SeenFileInsertResultIt != SeenFileEntries.end() &&
|
|
|
|
"unexpected SeenFileEntries cache miss");
|
|
|
|
SeenFileInsertResultIt->second = Redirect;
|
|
|
|
NamedFileEnt = &*SeenFileInsertResultIt;
|
2014-09-09 00:15:54 +08:00
|
|
|
}
|
|
|
|
|
2014-02-28 01:23:33 +08:00
|
|
|
if (UFE.isValid()) { // Already have an entry with this inode, return it.
|
2014-05-24 02:15:47 +08:00
|
|
|
|
|
|
|
// FIXME: this hack ensures that if we look up a file by a virtual path in
|
|
|
|
// the VFS that the getDir() will have the virtual path, even if we found
|
|
|
|
// the file by a 'real' path first. This is required in order to find a
|
|
|
|
// module's structure when its headers/module map are mapped in the VFS.
|
|
|
|
// We should remove this as soon as we can properly support a file having
|
|
|
|
// multiple names.
|
2019-03-05 10:27:12 +08:00
|
|
|
if (DirInfo != UFE.Dir && Status.IsVFSMapped)
|
2014-05-24 02:15:47 +08:00
|
|
|
UFE.Dir = DirInfo;
|
|
|
|
|
2014-08-13 20:34:41 +08:00
|
|
|
// Always update the name to use the last name by which a file was accessed.
|
|
|
|
// FIXME: Neither this nor always using the first name is correct; we want
|
|
|
|
// to switch towards a design where we return a FileName object that
|
|
|
|
// encapsulates both the name by which the file was accessed and the
|
|
|
|
// corresponding FileEntry.
|
Introduce FileEntryRef and use it when handling includes to report correct dependencies
when the FileManager is reused across invocations
This commit introduces a parallel API to FileManager's getFile: getFileEntryRef, which returns
a reference to the FileEntry, and the name that was used to access the file. In the case of
a VFS with 'use-external-names', the FileEntyRef contains the external name of the file,
not the filename that was used to access it.
The new API is adopted only in the HeaderSearch and Preprocessor for include file lookup, so that the
accessed path can be propagated to SourceManager's FileInfo. SourceManager's FileInfo now can report this accessed path, using
the new getName method. This API is then adopted in the dependency collector, which now correctly reports dependencies when a file
is included both using a symlink and a real path in the case when the FileManager is reused across multiple Preprocessor invocations.
Note that this patch does not fix all dependency collector issues, as the same problem is still present in other cases when dependencies
are obtained using FileSkipped, InclusionDirective, and HasInclude. This will be fixed in follow-up commits.
Differential Revision: https://reviews.llvm.org/D65907
llvm-svn: 369680
2019-08-23 02:15:50 +08:00
|
|
|
// FIXME: The Name should be removed from FileEntry once all clients
|
|
|
|
// adopt FileEntryRef.
|
2014-09-09 00:15:54 +08:00
|
|
|
UFE.Name = InterndFileName;
|
2014-08-13 20:34:41 +08:00
|
|
|
|
Introduce FileEntryRef and use it when handling includes to report correct dependencies
when the FileManager is reused across invocations
This commit introduces a parallel API to FileManager's getFile: getFileEntryRef, which returns
a reference to the FileEntry, and the name that was used to access the file. In the case of
a VFS with 'use-external-names', the FileEntyRef contains the external name of the file,
not the filename that was used to access it.
The new API is adopted only in the HeaderSearch and Preprocessor for include file lookup, so that the
accessed path can be propagated to SourceManager's FileInfo. SourceManager's FileInfo now can report this accessed path, using
the new getName method. This API is then adopted in the dependency collector, which now correctly reports dependencies when a file
is included both using a symlink and a real path in the case when the FileManager is reused across multiple Preprocessor invocations.
Note that this patch does not fix all dependency collector issues, as the same problem is still present in other cases when dependencies
are obtained using FileSkipped, InclusionDirective, and HasInclude. This will be fixed in follow-up commits.
Differential Revision: https://reviews.llvm.org/D65907
llvm-svn: 369680
2019-08-23 02:15:50 +08:00
|
|
|
return FileEntryRef(InterndFileName, UFE);
|
2010-11-24 05:17:56 +08:00
|
|
|
}
|
2006-06-25 14:23:00 +08:00
|
|
|
|
2014-02-28 06:21:32 +08:00
|
|
|
// Otherwise, we don't have this file yet, add it.
|
2014-09-09 00:15:54 +08:00
|
|
|
UFE.Name = InterndFileName;
|
2019-03-05 10:27:12 +08:00
|
|
|
UFE.Size = Status.getSize();
|
|
|
|
UFE.ModTime = llvm::sys::toTimeT(Status.getLastModificationTime());
|
2006-10-30 11:55:17 +08:00
|
|
|
UFE.Dir = DirInfo;
|
|
|
|
UFE.UID = NextFileUID++;
|
2019-03-05 10:27:12 +08:00
|
|
|
UFE.UniqueID = Status.getUniqueID();
|
|
|
|
UFE.IsNamedPipe = Status.getType() == llvm::sys::fs::file_type::fifo_file;
|
[FileManager] Revert r347205 to avoid PCH file-descriptor leak.
Summary:
r347205 fixed a bug in FileManager: first calling
getFile(shouldOpen=false) and then getFile(shouldOpen=true) results in
the file not being open.
Unfortunately, some code was (inadvertently?) relying on this bug: when
building with a PCH, the file entries are obtained first by passing
shouldOpen=false, and then later shouldOpen=true, without any intention
of reading them. After r347205, they do get unneccesarily opened.
Aside from extra operations, this means they need to be closed. Normally
files are closed when their contents are read. As these files are never
read, they stay open until clang exits. On platforms with a low
open-files limit (e.g. Mac), this can lead to spurious file-not-found
errors when building large projects with PCH enabled, e.g.
https://bugs.chromium.org/p/chromium/issues/detail?id=924225
Fixing the callsites to pass shouldOpen=false when the file won't be
read is not quite trivial (that info isn't available at the direct
callsite), and passing shouldOpen=false is a performance regression (it
results in open+fstat pairs being replaced by stat+open).
So an ideal fix is going to be a little risky and we need some fix soon
(especially for the llvm 8 branch).
The problem addressed by r347205 is rare and has only been observed in
clangd. It was present in llvm-7, so we can live with it for now.
Reviewers: bkramer, thakis
Subscribers: ilya-biryukov, ioeric, kadircet, cfe-commits
Differential Revision: https://reviews.llvm.org/D57165
llvm-svn: 352079
2019-01-25 02:55:24 +08:00
|
|
|
UFE.File = std::move(F);
|
2014-02-28 01:23:33 +08:00
|
|
|
UFE.IsValid = true;
|
[VirtualFileSystem] InMemoryFileSystem::status: Return a Status with the requested name
Summary:
InMemoryFileSystem::status behaves differently than
RealFileSystem::status. The Name contained in the Status returned by
RealFileSystem::status will be the path as requested by the caller,
whereas InMemoryFileSystem::status returns the normalized path.
For example, when requested the status for "../src/first.h",
RealFileSystem returns a Status with "../src/first.h" as the Name.
InMemoryFileSystem returns "/absolute/path/to/src/first.h".
The reason for this change is that I want to make a unit test in the
clangd testsuite (where we use an InMemoryFileSystem) to reproduce a
bug I get with the clangd program (where a RealFileSystem is used).
This difference in behavior "hides" the bug in the unit test version.
An indirect impact of this change is that a -Wnonportable-include-path
warning is now emitted in test PCH/case-insensitive-include.c. This is
because the real path of the included file (with the wrong case) was not
available previously, whereas it is now.
Reviewers: malaperle, ilya-biryukov, bkramer
Reviewed By: ilya-biryukov
Subscribers: eric_niebler, malaperle, omtcyfz, hokein, bkramer, ilya-biryukov, ioeric, cfe-commits
Differential Revision: https://reviews.llvm.org/D48903
llvm-svn: 339063
2018-08-07 05:48:20 +08:00
|
|
|
|
[FileManager] Revert r347205 to avoid PCH file-descriptor leak.
Summary:
r347205 fixed a bug in FileManager: first calling
getFile(shouldOpen=false) and then getFile(shouldOpen=true) results in
the file not being open.
Unfortunately, some code was (inadvertently?) relying on this bug: when
building with a PCH, the file entries are obtained first by passing
shouldOpen=false, and then later shouldOpen=true, without any intention
of reading them. After r347205, they do get unneccesarily opened.
Aside from extra operations, this means they need to be closed. Normally
files are closed when their contents are read. As these files are never
read, they stay open until clang exits. On platforms with a low
open-files limit (e.g. Mac), this can lead to spurious file-not-found
errors when building large projects with PCH enabled, e.g.
https://bugs.chromium.org/p/chromium/issues/detail?id=924225
Fixing the callsites to pass shouldOpen=false when the file won't be
read is not quite trivial (that info isn't available at the direct
callsite), and passing shouldOpen=false is a performance regression (it
results in open+fstat pairs being replaced by stat+open).
So an ideal fix is going to be a little risky and we need some fix soon
(especially for the llvm 8 branch).
The problem addressed by r347205 is rare and has only been observed in
clangd. It was present in llvm-7, so we can live with it for now.
Reviewers: bkramer, thakis
Subscribers: ilya-biryukov, ioeric, kadircet, cfe-commits
Differential Revision: https://reviews.llvm.org/D57165
llvm-svn: 352079
2019-01-25 02:55:24 +08:00
|
|
|
if (UFE.File) {
|
|
|
|
if (auto PathName = UFE.File->getName())
|
|
|
|
fillRealPathName(&UFE, *PathName);
|
2019-02-19 06:33:40 +08:00
|
|
|
} else if (!openFile) {
|
|
|
|
// We should still fill the path even if we aren't opening the file.
|
|
|
|
fillRealPathName(&UFE, InterndFileName);
|
[FileManager] Revert r347205 to avoid PCH file-descriptor leak.
Summary:
r347205 fixed a bug in FileManager: first calling
getFile(shouldOpen=false) and then getFile(shouldOpen=true) results in
the file not being open.
Unfortunately, some code was (inadvertently?) relying on this bug: when
building with a PCH, the file entries are obtained first by passing
shouldOpen=false, and then later shouldOpen=true, without any intention
of reading them. After r347205, they do get unneccesarily opened.
Aside from extra operations, this means they need to be closed. Normally
files are closed when their contents are read. As these files are never
read, they stay open until clang exits. On platforms with a low
open-files limit (e.g. Mac), this can lead to spurious file-not-found
errors when building large projects with PCH enabled, e.g.
https://bugs.chromium.org/p/chromium/issues/detail?id=924225
Fixing the callsites to pass shouldOpen=false when the file won't be
read is not quite trivial (that info isn't available at the direct
callsite), and passing shouldOpen=false is a performance regression (it
results in open+fstat pairs being replaced by stat+open).
So an ideal fix is going to be a little risky and we need some fix soon
(especially for the llvm 8 branch).
The problem addressed by r347205 is rare and has only been observed in
clangd. It was present in llvm-7, so we can live with it for now.
Reviewers: bkramer, thakis
Subscribers: ilya-biryukov, ioeric, kadircet, cfe-commits
Differential Revision: https://reviews.llvm.org/D57165
llvm-svn: 352079
2019-01-25 02:55:24 +08:00
|
|
|
}
|
Introduce FileEntryRef and use it when handling includes to report correct dependencies
when the FileManager is reused across invocations
This commit introduces a parallel API to FileManager's getFile: getFileEntryRef, which returns
a reference to the FileEntry, and the name that was used to access the file. In the case of
a VFS with 'use-external-names', the FileEntyRef contains the external name of the file,
not the filename that was used to access it.
The new API is adopted only in the HeaderSearch and Preprocessor for include file lookup, so that the
accessed path can be propagated to SourceManager's FileInfo. SourceManager's FileInfo now can report this accessed path, using
the new getName method. This API is then adopted in the dependency collector, which now correctly reports dependencies when a file
is included both using a symlink and a real path in the case when the FileManager is reused across multiple Preprocessor invocations.
Note that this patch does not fix all dependency collector issues, as the same problem is still present in other cases when dependencies
are obtained using FileSkipped, InclusionDirective, and HasInclude. This will be fixed in follow-up commits.
Differential Revision: https://reviews.llvm.org/D65907
llvm-svn: 369680
2019-08-23 02:15:50 +08:00
|
|
|
return FileEntryRef(InterndFileName, UFE);
|
2006-06-18 13:43:12 +08:00
|
|
|
}
|
|
|
|
|
2009-12-03 02:12:28 +08:00
|
|
|
const FileEntry *
|
2011-07-23 18:55:15 +08:00
|
|
|
FileManager::getVirtualFile(StringRef Filename, off_t Size,
|
2010-11-23 16:35:12 +08:00
|
|
|
time_t ModificationTime) {
|
2009-12-03 02:12:28 +08:00
|
|
|
++NumFileLookups;
|
|
|
|
|
2019-01-30 10:23:34 +08:00
|
|
|
// See if there is already an entry in the map for an existing file.
|
2019-08-02 05:31:49 +08:00
|
|
|
auto &NamedFileEnt = *SeenFileEntries.insert(
|
|
|
|
{Filename, std::errc::no_such_file_or_directory}).first;
|
Introduce FileEntryRef and use it when handling includes to report correct dependencies
when the FileManager is reused across invocations
This commit introduces a parallel API to FileManager's getFile: getFileEntryRef, which returns
a reference to the FileEntry, and the name that was used to access the file. In the case of
a VFS with 'use-external-names', the FileEntyRef contains the external name of the file,
not the filename that was used to access it.
The new API is adopted only in the HeaderSearch and Preprocessor for include file lookup, so that the
accessed path can be propagated to SourceManager's FileInfo. SourceManager's FileInfo now can report this accessed path, using
the new getName method. This API is then adopted in the dependency collector, which now correctly reports dependencies when a file
is included both using a symlink and a real path in the case when the FileManager is reused across multiple Preprocessor invocations.
Note that this patch does not fix all dependency collector issues, as the same problem is still present in other cases when dependencies
are obtained using FileSkipped, InclusionDirective, and HasInclude. This will be fixed in follow-up commits.
Differential Revision: https://reviews.llvm.org/D65907
llvm-svn: 369680
2019-08-23 02:15:50 +08:00
|
|
|
if (NamedFileEnt.second) {
|
|
|
|
SeenFileEntryOrRedirect Value = *NamedFileEnt.second;
|
|
|
|
FileEntry *FE;
|
|
|
|
if (LLVM_LIKELY(FE = Value.dyn_cast<FileEntry *>()))
|
|
|
|
return FE;
|
|
|
|
return getVirtualFile(*Value.get<const StringRef *>(), Size,
|
|
|
|
ModificationTime);
|
|
|
|
}
|
2009-12-03 02:12:28 +08:00
|
|
|
|
2019-01-30 10:23:34 +08:00
|
|
|
// We've not seen this before, or the file is cached as non-existent.
|
2009-12-03 02:12:28 +08:00
|
|
|
++NumFileCacheMisses;
|
2011-02-12 02:44:49 +08:00
|
|
|
addAncestorsAsVirtualDirs(Filename);
|
2014-05-08 14:41:40 +08:00
|
|
|
FileEntry *UFE = nullptr;
|
2011-02-12 02:44:49 +08:00
|
|
|
|
|
|
|
// Now that all ancestors of Filename are in the cache, the
|
|
|
|
// following call is guaranteed to find the DirectoryEntry from the
|
|
|
|
// cache.
|
2019-08-02 05:31:49 +08:00
|
|
|
auto DirInfo = getDirectoryFromFile(*this, Filename, /*CacheFailure=*/true);
|
2011-02-12 02:44:49 +08:00
|
|
|
assert(DirInfo &&
|
|
|
|
"The directory of a virtual file should already be in the cache.");
|
|
|
|
|
|
|
|
// Check to see if the file exists. If so, drop the virtual file
|
2019-03-05 10:27:12 +08:00
|
|
|
llvm::vfs::Status Status;
|
2014-11-19 11:06:06 +08:00
|
|
|
const char *InterndFileName = NamedFileEnt.first().data();
|
2019-08-02 05:31:49 +08:00
|
|
|
if (!getStatValue(InterndFileName, Status, true, nullptr)) {
|
2019-03-05 10:27:12 +08:00
|
|
|
UFE = &UniqueRealFiles[Status.getUniqueID()];
|
|
|
|
Status = llvm::vfs::Status(
|
|
|
|
Status.getName(), Status.getUniqueID(),
|
|
|
|
llvm::sys::toTimePoint(ModificationTime),
|
|
|
|
Status.getUser(), Status.getGroup(), Size,
|
|
|
|
Status.getType(), Status.getPermissions());
|
2011-02-12 02:44:49 +08:00
|
|
|
|
Introduce FileEntryRef and use it when handling includes to report correct dependencies
when the FileManager is reused across invocations
This commit introduces a parallel API to FileManager's getFile: getFileEntryRef, which returns
a reference to the FileEntry, and the name that was used to access the file. In the case of
a VFS with 'use-external-names', the FileEntyRef contains the external name of the file,
not the filename that was used to access it.
The new API is adopted only in the HeaderSearch and Preprocessor for include file lookup, so that the
accessed path can be propagated to SourceManager's FileInfo. SourceManager's FileInfo now can report this accessed path, using
the new getName method. This API is then adopted in the dependency collector, which now correctly reports dependencies when a file
is included both using a symlink and a real path in the case when the FileManager is reused across multiple Preprocessor invocations.
Note that this patch does not fix all dependency collector issues, as the same problem is still present in other cases when dependencies
are obtained using FileSkipped, InclusionDirective, and HasInclude. This will be fixed in follow-up commits.
Differential Revision: https://reviews.llvm.org/D65907
llvm-svn: 369680
2019-08-23 02:15:50 +08:00
|
|
|
NamedFileEnt.second = UFE;
|
2011-02-12 02:44:49 +08:00
|
|
|
|
|
|
|
// If we had already opened this file, close it now so we don't
|
|
|
|
// leak the descriptor. We're not going to use the file
|
|
|
|
// descriptor anyway, since this is a virtual file.
|
2014-02-21 05:59:23 +08:00
|
|
|
if (UFE->File)
|
|
|
|
UFE->closeFile();
|
2011-02-12 02:44:49 +08:00
|
|
|
|
|
|
|
// If we already have an entry with this inode, return it.
|
2014-02-28 01:23:33 +08:00
|
|
|
if (UFE->isValid())
|
2011-02-12 02:44:49 +08:00
|
|
|
return UFE;
|
2014-02-28 06:21:32 +08:00
|
|
|
|
2019-03-05 10:27:12 +08:00
|
|
|
UFE->UniqueID = Status.getUniqueID();
|
|
|
|
UFE->IsNamedPipe = Status.getType() == llvm::sys::fs::file_type::fifo_file;
|
|
|
|
fillRealPathName(UFE, Status.getName());
|
2019-01-30 10:23:34 +08:00
|
|
|
} else {
|
2019-08-15 07:04:18 +08:00
|
|
|
VirtualFileEntries.push_back(std::make_unique<FileEntry>());
|
2015-12-10 01:23:13 +08:00
|
|
|
UFE = VirtualFileEntries.back().get();
|
Introduce FileEntryRef and use it when handling includes to report correct dependencies
when the FileManager is reused across invocations
This commit introduces a parallel API to FileManager's getFile: getFileEntryRef, which returns
a reference to the FileEntry, and the name that was used to access the file. In the case of
a VFS with 'use-external-names', the FileEntyRef contains the external name of the file,
not the filename that was used to access it.
The new API is adopted only in the HeaderSearch and Preprocessor for include file lookup, so that the
accessed path can be propagated to SourceManager's FileInfo. SourceManager's FileInfo now can report this accessed path, using
the new getName method. This API is then adopted in the dependency collector, which now correctly reports dependencies when a file
is included both using a symlink and a real path in the case when the FileManager is reused across multiple Preprocessor invocations.
Note that this patch does not fix all dependency collector issues, as the same problem is still present in other cases when dependencies
are obtained using FileSkipped, InclusionDirective, and HasInclude. This will be fixed in follow-up commits.
Differential Revision: https://reviews.llvm.org/D65907
llvm-svn: 369680
2019-08-23 02:15:50 +08:00
|
|
|
NamedFileEnt.second = UFE;
|
2011-02-06 03:42:43 +08:00
|
|
|
}
|
2009-12-03 02:12:28 +08:00
|
|
|
|
2010-11-24 04:50:22 +08:00
|
|
|
UFE->Name = InterndFileName;
|
2009-12-03 02:12:28 +08:00
|
|
|
UFE->Size = Size;
|
|
|
|
UFE->ModTime = ModificationTime;
|
2019-08-02 05:31:49 +08:00
|
|
|
UFE->Dir = *DirInfo;
|
2009-12-03 02:12:28 +08:00
|
|
|
UFE->UID = NextFileUID++;
|
2017-03-28 17:18:05 +08:00
|
|
|
UFE->IsValid = true;
|
2014-02-21 05:59:23 +08:00
|
|
|
UFE->File.reset();
|
2009-12-03 02:12:28 +08:00
|
|
|
return UFE;
|
|
|
|
}
|
|
|
|
|
2019-08-31 06:59:25 +08:00
|
|
|
llvm::Optional<FileEntryRef> FileManager::getBypassFile(FileEntryRef VF) {
|
|
|
|
// Stat of the file and return nullptr if it doesn't exist.
|
|
|
|
llvm::vfs::Status Status;
|
|
|
|
if (getStatValue(VF.getName(), Status, /*isFile=*/true, /*F=*/nullptr))
|
|
|
|
return None;
|
|
|
|
|
|
|
|
// Fill it in from the stat.
|
|
|
|
BypassFileEntries.push_back(std::make_unique<FileEntry>());
|
|
|
|
const FileEntry &VFE = VF.getFileEntry();
|
|
|
|
FileEntry &BFE = *BypassFileEntries.back();
|
|
|
|
BFE.Name = VFE.getName();
|
|
|
|
BFE.Size = Status.getSize();
|
|
|
|
BFE.Dir = VFE.Dir;
|
|
|
|
BFE.ModTime = llvm::sys::toTimeT(Status.getLastModificationTime());
|
|
|
|
BFE.UID = NextFileUID++;
|
|
|
|
BFE.IsValid = true;
|
|
|
|
return FileEntryRef(VF.getName(), BFE);
|
|
|
|
}
|
|
|
|
|
2015-07-31 08:58:32 +08:00
|
|
|
bool FileManager::FixupRelativePath(SmallVectorImpl<char> &path) const {
|
2011-07-23 18:55:15 +08:00
|
|
|
StringRef pathRef(path.data(), path.size());
|
2011-03-07 06:25:35 +08:00
|
|
|
|
2018-07-31 03:24:48 +08:00
|
|
|
if (FileSystemOpts.WorkingDir.empty()
|
2011-03-14 09:13:54 +08:00
|
|
|
|| llvm::sys::path::is_absolute(pathRef))
|
2015-07-31 08:58:32 +08:00
|
|
|
return false;
|
2010-12-18 05:22:22 +08:00
|
|
|
|
2012-02-05 10:13:05 +08:00
|
|
|
SmallString<128> NewPath(FileSystemOpts.WorkingDir);
|
2011-03-07 06:25:35 +08:00
|
|
|
llvm::sys::path::append(NewPath, pathRef);
|
2010-11-23 12:45:28 +08:00
|
|
|
path = NewPath;
|
2015-07-31 08:58:32 +08:00
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
|
|
|
bool FileManager::makeAbsolutePath(SmallVectorImpl<char> &Path) const {
|
|
|
|
bool Changed = FixupRelativePath(Path);
|
|
|
|
|
|
|
|
if (!llvm::sys::path::is_absolute(StringRef(Path.data(), Path.size()))) {
|
2017-08-02 15:25:24 +08:00
|
|
|
FS->makeAbsolute(Path);
|
2015-07-31 08:58:32 +08:00
|
|
|
Changed = true;
|
|
|
|
}
|
|
|
|
|
|
|
|
return Changed;
|
2010-11-23 12:45:28 +08:00
|
|
|
}
|
|
|
|
|
2018-12-01 01:10:11 +08:00
|
|
|
void FileManager::fillRealPathName(FileEntry *UFE, llvm::StringRef FileName) {
|
|
|
|
llvm::SmallString<128> AbsPath(FileName);
|
|
|
|
// This is not the same as `VFS::getRealPath()`, which resolves symlinks
|
|
|
|
// but can be very expensive on real file systems.
|
|
|
|
// FIXME: the semantic of RealPathName is unclear, and the name might be
|
|
|
|
// misleading. We need to clean up the interface here.
|
|
|
|
makeAbsolutePath(AbsPath);
|
|
|
|
llvm::sys::path::remove_dots(AbsPath, /*remove_dot_dot=*/true);
|
2020-01-29 03:23:46 +08:00
|
|
|
UFE->RealPathName = std::string(AbsPath.str());
|
2018-12-01 01:10:11 +08:00
|
|
|
}
|
|
|
|
|
2014-10-27 06:44:13 +08:00
|
|
|
llvm::ErrorOr<std::unique_ptr<llvm::MemoryBuffer>>
|
2020-04-09 11:29:39 +08:00
|
|
|
FileManager::getBufferForFile(const FileEntry *Entry, bool isVolatile,
|
|
|
|
bool RequiresNullTerminator) {
|
2012-07-12 04:59:04 +08:00
|
|
|
uint64_t FileSize = Entry->getSize();
|
|
|
|
// If there's a high enough chance that the file have changed since we
|
|
|
|
// got its size, force a stat before opening it.
|
|
|
|
if (isVolatile)
|
|
|
|
FileSize = -1;
|
|
|
|
|
2016-10-11 06:52:47 +08:00
|
|
|
StringRef Filename = Entry->getName();
|
2011-03-15 08:47:44 +08:00
|
|
|
// If the file is already open, use the open file descriptor.
|
2014-02-21 05:59:23 +08:00
|
|
|
if (Entry->File) {
|
2020-04-09 11:29:39 +08:00
|
|
|
auto Result = Entry->File->getBuffer(Filename, FileSize,
|
|
|
|
RequiresNullTerminator, isVolatile);
|
2019-08-31 00:56:26 +08:00
|
|
|
Entry->closeFile();
|
2014-08-27 03:54:40 +08:00
|
|
|
return Result;
|
2011-03-15 08:47:44 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
// Otherwise, open the file.
|
2020-04-09 11:29:39 +08:00
|
|
|
return getBufferForFileImpl(Filename, FileSize, isVolatile,
|
|
|
|
RequiresNullTerminator);
|
2019-08-25 09:18:35 +08:00
|
|
|
}
|
2011-03-15 08:47:44 +08:00
|
|
|
|
2019-08-25 09:18:35 +08:00
|
|
|
llvm::ErrorOr<std::unique_ptr<llvm::MemoryBuffer>>
|
|
|
|
FileManager::getBufferForFileImpl(StringRef Filename, int64_t FileSize,
|
2020-04-09 11:29:39 +08:00
|
|
|
bool isVolatile,
|
|
|
|
bool RequiresNullTerminator) {
|
2014-10-27 06:44:13 +08:00
|
|
|
if (FileSystemOpts.WorkingDir.empty())
|
2020-04-09 11:29:39 +08:00
|
|
|
return FS->getBufferForFile(Filename, FileSize, RequiresNullTerminator,
|
|
|
|
isVolatile);
|
2011-03-07 06:25:35 +08:00
|
|
|
|
2019-08-25 09:18:35 +08:00
|
|
|
SmallString<128> FilePath(Filename);
|
2011-03-07 09:28:33 +08:00
|
|
|
FixupRelativePath(FilePath);
|
2020-04-09 11:29:39 +08:00
|
|
|
return FS->getBufferForFile(FilePath, FileSize, RequiresNullTerminator,
|
|
|
|
isVolatile);
|
2010-11-23 17:19:42 +08:00
|
|
|
}
|
2010-11-23 12:45:28 +08:00
|
|
|
|
2011-02-12 02:44:49 +08:00
|
|
|
/// getStatValue - Get the 'stat' information for the specified path,
|
|
|
|
/// using the cache to accelerate it if possible. This returns true
|
|
|
|
/// if the path points to a virtual file or does not exist, or returns
|
|
|
|
/// false if it's an existent real file. If FileDescriptor is NULL,
|
|
|
|
/// do directory look-up instead of file look-up.
|
2019-08-02 05:31:49 +08:00
|
|
|
std::error_code
|
|
|
|
FileManager::getStatValue(StringRef Path, llvm::vfs::Status &Status,
|
|
|
|
bool isFile, std::unique_ptr<llvm::vfs::File> *F) {
|
2010-11-24 03:19:34 +08:00
|
|
|
// FIXME: FileSystemOpts shouldn't be passed in here, all paths should be
|
|
|
|
// absolute!
|
2010-11-24 03:56:39 +08:00
|
|
|
if (FileSystemOpts.WorkingDir.empty())
|
2019-08-02 05:31:49 +08:00
|
|
|
return FileSystemStatCache::get(Path, Status, isFile, F,
|
|
|
|
StatCache.get(), *FS);
|
2011-02-12 02:44:49 +08:00
|
|
|
|
2012-02-05 10:13:05 +08:00
|
|
|
SmallString<128> FilePath(Path);
|
2011-03-07 09:28:33 +08:00
|
|
|
FixupRelativePath(FilePath);
|
2010-11-24 03:56:39 +08:00
|
|
|
|
2019-08-02 05:31:49 +08:00
|
|
|
return FileSystemStatCache::get(FilePath.c_str(), Status, isFile, F,
|
|
|
|
StatCache.get(), *FS);
|
2010-11-04 06:45:23 +08:00
|
|
|
}
|
|
|
|
|
2020-02-18 10:48:38 +08:00
|
|
|
std::error_code
|
2019-08-02 05:31:49 +08:00
|
|
|
FileManager::getNoncachedStatValue(StringRef Path,
|
|
|
|
llvm::vfs::Status &Result) {
|
2012-02-05 10:13:05 +08:00
|
|
|
SmallString<128> FilePath(Path);
|
2011-03-19 03:23:19 +08:00
|
|
|
FixupRelativePath(FilePath);
|
|
|
|
|
2018-10-10 21:27:25 +08:00
|
|
|
llvm::ErrorOr<llvm::vfs::Status> S = FS->status(FilePath.c_str());
|
2014-02-21 05:59:23 +08:00
|
|
|
if (!S)
|
2019-08-02 05:31:49 +08:00
|
|
|
return S.getError();
|
2014-02-21 05:59:23 +08:00
|
|
|
Result = *S;
|
2019-08-02 05:31:49 +08:00
|
|
|
return std::error_code();
|
2011-03-19 03:23:19 +08:00
|
|
|
}
|
|
|
|
|
Implement two related optimizations that make de-serialization of
AST/PCH files more lazy:
- Don't preload all of the file source-location entries when reading
the AST file. Instead, load them lazily, when needed.
- Only look up header-search information (whether a header was already
#import'd, how many times it's been included, etc.) when it's needed
by the preprocessor, rather than pre-populating it.
Previously, we would pre-load all of the file source-location entries,
which also populated the header-search information structure. This was
a relatively minor performance issue, since we would end up stat()'ing
all of the headers stored within a AST/PCH file when the AST/PCH file
was loaded. In the normal PCH use case, the stat()s were cached, so
the cost--of preloading ~860 source-location entries in the Cocoa.h
case---was relatively low.
However, the recent optimization that replaced stat+open with
open+fstat turned this into a major problem, since the preloading of
source-location entries would now end up opening those files. Worse,
those files wouldn't be closed until the file manager was destroyed,
so just opening a Cocoa.h PCH file would hold on to ~860 file
descriptors, and it was easy to blow through the process's limit on
the number of open file descriptors.
By eliminating the preloading of these files, we neither open nor stat
the headers stored in the PCH/AST file until they're actually needed
for something. Concretely, we went from
*** HeaderSearch Stats:
835 files tracked.
364 #import/#pragma once files.
823 included exactly once.
6 max times a file is included.
3 #include/#include_next/#import.
0 #includes skipped due to the multi-include optimization.
1 framework lookups.
0 subframework lookups.
*** Source Manager Stats:
835 files mapped, 3 mem buffers mapped.
37460 SLocEntry's allocated, 11215575B of Sloc address space used.
62 bytes of files mapped, 0 files with line #'s computed.
with a trivial program that uses a chained PCH including a Cocoa PCH
to
*** HeaderSearch Stats:
4 files tracked.
1 #import/#pragma once files.
3 included exactly once.
2 max times a file is included.
3 #include/#include_next/#import.
0 #includes skipped due to the multi-include optimization.
1 framework lookups.
0 subframework lookups.
*** Source Manager Stats:
3 files mapped, 3 mem buffers mapped.
37460 SLocEntry's allocated, 11215575B of Sloc address space used.
62 bytes of files mapped, 0 files with line #'s computed.
for the same program.
llvm-svn: 125286
2011-02-11 01:09:37 +08:00
|
|
|
void FileManager::GetUniqueIDMapping(
|
2011-07-23 18:55:15 +08:00
|
|
|
SmallVectorImpl<const FileEntry *> &UIDToFiles) const {
|
Implement two related optimizations that make de-serialization of
AST/PCH files more lazy:
- Don't preload all of the file source-location entries when reading
the AST file. Instead, load them lazily, when needed.
- Only look up header-search information (whether a header was already
#import'd, how many times it's been included, etc.) when it's needed
by the preprocessor, rather than pre-populating it.
Previously, we would pre-load all of the file source-location entries,
which also populated the header-search information structure. This was
a relatively minor performance issue, since we would end up stat()'ing
all of the headers stored within a AST/PCH file when the AST/PCH file
was loaded. In the normal PCH use case, the stat()s were cached, so
the cost--of preloading ~860 source-location entries in the Cocoa.h
case---was relatively low.
However, the recent optimization that replaced stat+open with
open+fstat turned this into a major problem, since the preloading of
source-location entries would now end up opening those files. Worse,
those files wouldn't be closed until the file manager was destroyed,
so just opening a Cocoa.h PCH file would hold on to ~860 file
descriptors, and it was easy to blow through the process's limit on
the number of open file descriptors.
By eliminating the preloading of these files, we neither open nor stat
the headers stored in the PCH/AST file until they're actually needed
for something. Concretely, we went from
*** HeaderSearch Stats:
835 files tracked.
364 #import/#pragma once files.
823 included exactly once.
6 max times a file is included.
3 #include/#include_next/#import.
0 #includes skipped due to the multi-include optimization.
1 framework lookups.
0 subframework lookups.
*** Source Manager Stats:
835 files mapped, 3 mem buffers mapped.
37460 SLocEntry's allocated, 11215575B of Sloc address space used.
62 bytes of files mapped, 0 files with line #'s computed.
with a trivial program that uses a chained PCH including a Cocoa PCH
to
*** HeaderSearch Stats:
4 files tracked.
1 #import/#pragma once files.
3 included exactly once.
2 max times a file is included.
3 #include/#include_next/#import.
0 #includes skipped due to the multi-include optimization.
1 framework lookups.
0 subframework lookups.
*** Source Manager Stats:
3 files mapped, 3 mem buffers mapped.
37460 SLocEntry's allocated, 11215575B of Sloc address space used.
62 bytes of files mapped, 0 files with line #'s computed.
for the same program.
llvm-svn: 125286
2011-02-11 01:09:37 +08:00
|
|
|
UIDToFiles.clear();
|
|
|
|
UIDToFiles.resize(NextFileUID);
|
2018-07-31 03:24:48 +08:00
|
|
|
|
Implement two related optimizations that make de-serialization of
AST/PCH files more lazy:
- Don't preload all of the file source-location entries when reading
the AST file. Instead, load them lazily, when needed.
- Only look up header-search information (whether a header was already
#import'd, how many times it's been included, etc.) when it's needed
by the preprocessor, rather than pre-populating it.
Previously, we would pre-load all of the file source-location entries,
which also populated the header-search information structure. This was
a relatively minor performance issue, since we would end up stat()'ing
all of the headers stored within a AST/PCH file when the AST/PCH file
was loaded. In the normal PCH use case, the stat()s were cached, so
the cost--of preloading ~860 source-location entries in the Cocoa.h
case---was relatively low.
However, the recent optimization that replaced stat+open with
open+fstat turned this into a major problem, since the preloading of
source-location entries would now end up opening those files. Worse,
those files wouldn't be closed until the file manager was destroyed,
so just opening a Cocoa.h PCH file would hold on to ~860 file
descriptors, and it was easy to blow through the process's limit on
the number of open file descriptors.
By eliminating the preloading of these files, we neither open nor stat
the headers stored in the PCH/AST file until they're actually needed
for something. Concretely, we went from
*** HeaderSearch Stats:
835 files tracked.
364 #import/#pragma once files.
823 included exactly once.
6 max times a file is included.
3 #include/#include_next/#import.
0 #includes skipped due to the multi-include optimization.
1 framework lookups.
0 subframework lookups.
*** Source Manager Stats:
835 files mapped, 3 mem buffers mapped.
37460 SLocEntry's allocated, 11215575B of Sloc address space used.
62 bytes of files mapped, 0 files with line #'s computed.
with a trivial program that uses a chained PCH including a Cocoa PCH
to
*** HeaderSearch Stats:
4 files tracked.
1 #import/#pragma once files.
3 included exactly once.
2 max times a file is included.
3 #include/#include_next/#import.
0 #includes skipped due to the multi-include optimization.
1 framework lookups.
0 subframework lookups.
*** Source Manager Stats:
3 files mapped, 3 mem buffers mapped.
37460 SLocEntry's allocated, 11215575B of Sloc address space used.
62 bytes of files mapped, 0 files with line #'s computed.
for the same program.
llvm-svn: 125286
2011-02-11 01:09:37 +08:00
|
|
|
// Map file entries
|
Introduce FileEntryRef and use it when handling includes to report correct dependencies
when the FileManager is reused across invocations
This commit introduces a parallel API to FileManager's getFile: getFileEntryRef, which returns
a reference to the FileEntry, and the name that was used to access the file. In the case of
a VFS with 'use-external-names', the FileEntyRef contains the external name of the file,
not the filename that was used to access it.
The new API is adopted only in the HeaderSearch and Preprocessor for include file lookup, so that the
accessed path can be propagated to SourceManager's FileInfo. SourceManager's FileInfo now can report this accessed path, using
the new getName method. This API is then adopted in the dependency collector, which now correctly reports dependencies when a file
is included both using a symlink and a real path in the case when the FileManager is reused across multiple Preprocessor invocations.
Note that this patch does not fix all dependency collector issues, as the same problem is still present in other cases when dependencies
are obtained using FileSkipped, InclusionDirective, and HasInclude. This will be fixed in follow-up commits.
Differential Revision: https://reviews.llvm.org/D65907
llvm-svn: 369680
2019-08-23 02:15:50 +08:00
|
|
|
for (llvm::StringMap<llvm::ErrorOr<SeenFileEntryOrRedirect>,
|
2019-08-02 05:31:49 +08:00
|
|
|
llvm::BumpPtrAllocator>::const_iterator
|
Introduce FileEntryRef and use it when handling includes to report correct dependencies
when the FileManager is reused across invocations
This commit introduces a parallel API to FileManager's getFile: getFileEntryRef, which returns
a reference to the FileEntry, and the name that was used to access the file. In the case of
a VFS with 'use-external-names', the FileEntyRef contains the external name of the file,
not the filename that was used to access it.
The new API is adopted only in the HeaderSearch and Preprocessor for include file lookup, so that the
accessed path can be propagated to SourceManager's FileInfo. SourceManager's FileInfo now can report this accessed path, using
the new getName method. This API is then adopted in the dependency collector, which now correctly reports dependencies when a file
is included both using a symlink and a real path in the case when the FileManager is reused across multiple Preprocessor invocations.
Note that this patch does not fix all dependency collector issues, as the same problem is still present in other cases when dependencies
are obtained using FileSkipped, InclusionDirective, and HasInclude. This will be fixed in follow-up commits.
Differential Revision: https://reviews.llvm.org/D65907
llvm-svn: 369680
2019-08-23 02:15:50 +08:00
|
|
|
FE = SeenFileEntries.begin(),
|
|
|
|
FEEnd = SeenFileEntries.end();
|
Implement two related optimizations that make de-serialization of
AST/PCH files more lazy:
- Don't preload all of the file source-location entries when reading
the AST file. Instead, load them lazily, when needed.
- Only look up header-search information (whether a header was already
#import'd, how many times it's been included, etc.) when it's needed
by the preprocessor, rather than pre-populating it.
Previously, we would pre-load all of the file source-location entries,
which also populated the header-search information structure. This was
a relatively minor performance issue, since we would end up stat()'ing
all of the headers stored within a AST/PCH file when the AST/PCH file
was loaded. In the normal PCH use case, the stat()s were cached, so
the cost--of preloading ~860 source-location entries in the Cocoa.h
case---was relatively low.
However, the recent optimization that replaced stat+open with
open+fstat turned this into a major problem, since the preloading of
source-location entries would now end up opening those files. Worse,
those files wouldn't be closed until the file manager was destroyed,
so just opening a Cocoa.h PCH file would hold on to ~860 file
descriptors, and it was easy to blow through the process's limit on
the number of open file descriptors.
By eliminating the preloading of these files, we neither open nor stat
the headers stored in the PCH/AST file until they're actually needed
for something. Concretely, we went from
*** HeaderSearch Stats:
835 files tracked.
364 #import/#pragma once files.
823 included exactly once.
6 max times a file is included.
3 #include/#include_next/#import.
0 #includes skipped due to the multi-include optimization.
1 framework lookups.
0 subframework lookups.
*** Source Manager Stats:
835 files mapped, 3 mem buffers mapped.
37460 SLocEntry's allocated, 11215575B of Sloc address space used.
62 bytes of files mapped, 0 files with line #'s computed.
with a trivial program that uses a chained PCH including a Cocoa PCH
to
*** HeaderSearch Stats:
4 files tracked.
1 #import/#pragma once files.
3 included exactly once.
2 max times a file is included.
3 #include/#include_next/#import.
0 #includes skipped due to the multi-include optimization.
1 framework lookups.
0 subframework lookups.
*** Source Manager Stats:
3 files mapped, 3 mem buffers mapped.
37460 SLocEntry's allocated, 11215575B of Sloc address space used.
62 bytes of files mapped, 0 files with line #'s computed.
for the same program.
llvm-svn: 125286
2011-02-11 01:09:37 +08:00
|
|
|
FE != FEEnd; ++FE)
|
Introduce FileEntryRef and use it when handling includes to report correct dependencies
when the FileManager is reused across invocations
This commit introduces a parallel API to FileManager's getFile: getFileEntryRef, which returns
a reference to the FileEntry, and the name that was used to access the file. In the case of
a VFS with 'use-external-names', the FileEntyRef contains the external name of the file,
not the filename that was used to access it.
The new API is adopted only in the HeaderSearch and Preprocessor for include file lookup, so that the
accessed path can be propagated to SourceManager's FileInfo. SourceManager's FileInfo now can report this accessed path, using
the new getName method. This API is then adopted in the dependency collector, which now correctly reports dependencies when a file
is included both using a symlink and a real path in the case when the FileManager is reused across multiple Preprocessor invocations.
Note that this patch does not fix all dependency collector issues, as the same problem is still present in other cases when dependencies
are obtained using FileSkipped, InclusionDirective, and HasInclude. This will be fixed in follow-up commits.
Differential Revision: https://reviews.llvm.org/D65907
llvm-svn: 369680
2019-08-23 02:15:50 +08:00
|
|
|
if (llvm::ErrorOr<SeenFileEntryOrRedirect> Entry = FE->getValue()) {
|
|
|
|
if (const auto *FE = (*Entry).dyn_cast<FileEntry *>())
|
|
|
|
UIDToFiles[FE->getUID()] = FE;
|
2019-08-02 05:31:49 +08:00
|
|
|
}
|
2018-07-31 03:24:48 +08:00
|
|
|
|
Implement two related optimizations that make de-serialization of
AST/PCH files more lazy:
- Don't preload all of the file source-location entries when reading
the AST file. Instead, load them lazily, when needed.
- Only look up header-search information (whether a header was already
#import'd, how many times it's been included, etc.) when it's needed
by the preprocessor, rather than pre-populating it.
Previously, we would pre-load all of the file source-location entries,
which also populated the header-search information structure. This was
a relatively minor performance issue, since we would end up stat()'ing
all of the headers stored within a AST/PCH file when the AST/PCH file
was loaded. In the normal PCH use case, the stat()s were cached, so
the cost--of preloading ~860 source-location entries in the Cocoa.h
case---was relatively low.
However, the recent optimization that replaced stat+open with
open+fstat turned this into a major problem, since the preloading of
source-location entries would now end up opening those files. Worse,
those files wouldn't be closed until the file manager was destroyed,
so just opening a Cocoa.h PCH file would hold on to ~860 file
descriptors, and it was easy to blow through the process's limit on
the number of open file descriptors.
By eliminating the preloading of these files, we neither open nor stat
the headers stored in the PCH/AST file until they're actually needed
for something. Concretely, we went from
*** HeaderSearch Stats:
835 files tracked.
364 #import/#pragma once files.
823 included exactly once.
6 max times a file is included.
3 #include/#include_next/#import.
0 #includes skipped due to the multi-include optimization.
1 framework lookups.
0 subframework lookups.
*** Source Manager Stats:
835 files mapped, 3 mem buffers mapped.
37460 SLocEntry's allocated, 11215575B of Sloc address space used.
62 bytes of files mapped, 0 files with line #'s computed.
with a trivial program that uses a chained PCH including a Cocoa PCH
to
*** HeaderSearch Stats:
4 files tracked.
1 #import/#pragma once files.
3 included exactly once.
2 max times a file is included.
3 #include/#include_next/#import.
0 #includes skipped due to the multi-include optimization.
1 framework lookups.
0 subframework lookups.
*** Source Manager Stats:
3 files mapped, 3 mem buffers mapped.
37460 SLocEntry's allocated, 11215575B of Sloc address space used.
62 bytes of files mapped, 0 files with line #'s computed.
for the same program.
llvm-svn: 125286
2011-02-11 01:09:37 +08:00
|
|
|
// Map virtual file entries
|
2015-12-10 01:23:13 +08:00
|
|
|
for (const auto &VFE : VirtualFileEntries)
|
2019-01-30 10:23:34 +08:00
|
|
|
UIDToFiles[VFE->getUID()] = VFE.get();
|
Implement two related optimizations that make de-serialization of
AST/PCH files more lazy:
- Don't preload all of the file source-location entries when reading
the AST file. Instead, load them lazily, when needed.
- Only look up header-search information (whether a header was already
#import'd, how many times it's been included, etc.) when it's needed
by the preprocessor, rather than pre-populating it.
Previously, we would pre-load all of the file source-location entries,
which also populated the header-search information structure. This was
a relatively minor performance issue, since we would end up stat()'ing
all of the headers stored within a AST/PCH file when the AST/PCH file
was loaded. In the normal PCH use case, the stat()s were cached, so
the cost--of preloading ~860 source-location entries in the Cocoa.h
case---was relatively low.
However, the recent optimization that replaced stat+open with
open+fstat turned this into a major problem, since the preloading of
source-location entries would now end up opening those files. Worse,
those files wouldn't be closed until the file manager was destroyed,
so just opening a Cocoa.h PCH file would hold on to ~860 file
descriptors, and it was easy to blow through the process's limit on
the number of open file descriptors.
By eliminating the preloading of these files, we neither open nor stat
the headers stored in the PCH/AST file until they're actually needed
for something. Concretely, we went from
*** HeaderSearch Stats:
835 files tracked.
364 #import/#pragma once files.
823 included exactly once.
6 max times a file is included.
3 #include/#include_next/#import.
0 #includes skipped due to the multi-include optimization.
1 framework lookups.
0 subframework lookups.
*** Source Manager Stats:
835 files mapped, 3 mem buffers mapped.
37460 SLocEntry's allocated, 11215575B of Sloc address space used.
62 bytes of files mapped, 0 files with line #'s computed.
with a trivial program that uses a chained PCH including a Cocoa PCH
to
*** HeaderSearch Stats:
4 files tracked.
1 #import/#pragma once files.
3 included exactly once.
2 max times a file is included.
3 #include/#include_next/#import.
0 #includes skipped due to the multi-include optimization.
1 framework lookups.
0 subframework lookups.
*** Source Manager Stats:
3 files mapped, 3 mem buffers mapped.
37460 SLocEntry's allocated, 11215575B of Sloc address space used.
62 bytes of files mapped, 0 files with line #'s computed.
for the same program.
llvm-svn: 125286
2011-02-11 01:09:37 +08:00
|
|
|
}
|
2010-11-24 03:19:34 +08:00
|
|
|
|
2013-01-26 08:55:12 +08:00
|
|
|
StringRef FileManager::getCanonicalName(const DirectoryEntry *Dir) {
|
2019-12-20 15:07:22 +08:00
|
|
|
llvm::DenseMap<const void *, llvm::StringRef>::iterator Known
|
|
|
|
= CanonicalNames.find(Dir);
|
|
|
|
if (Known != CanonicalNames.end())
|
2013-01-26 08:55:12 +08:00
|
|
|
return Known->second;
|
|
|
|
|
|
|
|
StringRef CanonicalName(Dir->getName());
|
2014-12-12 04:50:24 +08:00
|
|
|
|
2018-05-17 18:26:23 +08:00
|
|
|
SmallString<4096> CanonicalNameBuf;
|
|
|
|
if (!FS->getRealPath(Dir->getName(), CanonicalNameBuf))
|
2015-08-04 19:27:08 +08:00
|
|
|
CanonicalName = StringRef(CanonicalNameBuf).copy(CanonicalNameStorage);
|
2013-01-26 08:55:12 +08:00
|
|
|
|
2019-12-20 15:07:22 +08:00
|
|
|
CanonicalNames.insert({Dir, CanonicalName});
|
|
|
|
return CanonicalName;
|
|
|
|
}
|
|
|
|
|
|
|
|
StringRef FileManager::getCanonicalName(const FileEntry *File) {
|
|
|
|
llvm::DenseMap<const void *, llvm::StringRef>::iterator Known
|
|
|
|
= CanonicalNames.find(File);
|
|
|
|
if (Known != CanonicalNames.end())
|
|
|
|
return Known->second;
|
|
|
|
|
|
|
|
StringRef CanonicalName(File->getName());
|
|
|
|
|
|
|
|
SmallString<4096> CanonicalNameBuf;
|
|
|
|
if (!FS->getRealPath(File->getName(), CanonicalNameBuf))
|
|
|
|
CanonicalName = StringRef(CanonicalNameBuf).copy(CanonicalNameStorage);
|
|
|
|
|
|
|
|
CanonicalNames.insert({File, CanonicalName});
|
2013-01-26 08:55:12 +08:00
|
|
|
return CanonicalName;
|
|
|
|
}
|
2010-11-24 03:19:34 +08:00
|
|
|
|
2006-06-18 13:43:12 +08:00
|
|
|
void FileManager::PrintStats() const {
|
2009-08-23 20:08:50 +08:00
|
|
|
llvm::errs() << "\n*** File Manager Stats:\n";
|
2011-02-12 02:44:49 +08:00
|
|
|
llvm::errs() << UniqueRealFiles.size() << " real files found, "
|
|
|
|
<< UniqueRealDirs.size() << " real dirs found.\n";
|
|
|
|
llvm::errs() << VirtualFileEntries.size() << " virtual files found, "
|
|
|
|
<< VirtualDirectoryEntries.size() << " virtual dirs found.\n";
|
2009-08-23 20:08:50 +08:00
|
|
|
llvm::errs() << NumDirLookups << " dir lookups, "
|
|
|
|
<< NumDirCacheMisses << " dir cache misses.\n";
|
|
|
|
llvm::errs() << NumFileLookups << " file lookups, "
|
|
|
|
<< NumFileCacheMisses << " file cache misses.\n";
|
2009-09-09 23:08:12 +08:00
|
|
|
|
2009-08-23 20:08:50 +08:00
|
|
|
//llvm::errs() << PagesMapped << BytesOfPagesMapped << FSLookups;
|
2006-06-18 13:43:12 +08:00
|
|
|
}
|