2018-03-29 06:09:09 +08:00
|
|
|
//===- VirtualFileSystem.cpp - Virtual File System Layer ------------------===//
|
2014-02-21 05:59:23 +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
|
2014-02-21 05:59:23 +08:00
|
|
|
//
|
|
|
|
//===----------------------------------------------------------------------===//
|
2018-03-29 06:09:09 +08:00
|
|
|
//
|
2014-02-21 05:59:23 +08:00
|
|
|
// This file implements the VirtualFileSystem interface.
|
2018-03-29 06:09:09 +08:00
|
|
|
//
|
2014-02-21 05:59:23 +08:00
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
|
2018-10-10 21:27:25 +08:00
|
|
|
#include "llvm/Support/VirtualFileSystem.h"
|
2018-03-29 06:09:09 +08:00
|
|
|
#include "llvm/ADT/ArrayRef.h"
|
2014-02-22 07:39:37 +08:00
|
|
|
#include "llvm/ADT/DenseMap.h"
|
2018-03-29 06:09:09 +08:00
|
|
|
#include "llvm/ADT/IntrusiveRefCntPtr.h"
|
2018-09-04 22:15:53 +08:00
|
|
|
#include "llvm/ADT/None.h"
|
2018-03-29 06:09:09 +08:00
|
|
|
#include "llvm/ADT/Optional.h"
|
2014-02-22 07:39:37 +08:00
|
|
|
#include "llvm/ADT/STLExtras.h"
|
2018-03-29 06:09:09 +08:00
|
|
|
#include "llvm/ADT/SmallString.h"
|
|
|
|
#include "llvm/ADT/SmallVector.h"
|
|
|
|
#include "llvm/ADT/StringRef.h"
|
2014-06-25 03:37:16 +08:00
|
|
|
#include "llvm/ADT/StringSet.h"
|
2018-03-29 06:09:09 +08:00
|
|
|
#include "llvm/ADT/Twine.h"
|
2015-01-14 19:29:14 +08:00
|
|
|
#include "llvm/ADT/iterator_range.h"
|
2016-05-27 22:27:13 +08:00
|
|
|
#include "llvm/Config/llvm-config.h"
|
2018-03-29 06:09:09 +08:00
|
|
|
#include "llvm/Support/Casting.h"
|
|
|
|
#include "llvm/Support/Chrono.h"
|
2018-09-04 22:15:53 +08:00
|
|
|
#include "llvm/Support/Compiler.h"
|
2016-05-07 07:21:57 +08:00
|
|
|
#include "llvm/Support/Debug.h"
|
2014-06-14 01:20:50 +08:00
|
|
|
#include "llvm/Support/Errc.h"
|
2018-03-29 06:09:09 +08:00
|
|
|
#include "llvm/Support/ErrorHandling.h"
|
|
|
|
#include "llvm/Support/ErrorOr.h"
|
|
|
|
#include "llvm/Support/FileSystem.h"
|
2014-02-21 05:59:23 +08:00
|
|
|
#include "llvm/Support/MemoryBuffer.h"
|
|
|
|
#include "llvm/Support/Path.h"
|
2016-03-04 13:26:14 +08:00
|
|
|
#include "llvm/Support/Process.h"
|
2018-03-29 06:09:09 +08:00
|
|
|
#include "llvm/Support/SMLoc.h"
|
|
|
|
#include "llvm/Support/SourceMgr.h"
|
2014-02-22 07:39:37 +08:00
|
|
|
#include "llvm/Support/YAMLParser.h"
|
2018-03-29 06:09:09 +08:00
|
|
|
#include "llvm/Support/raw_ostream.h"
|
|
|
|
#include <algorithm>
|
2014-03-03 01:08:31 +08:00
|
|
|
#include <atomic>
|
2018-03-29 06:09:09 +08:00
|
|
|
#include <cassert>
|
|
|
|
#include <cstdint>
|
|
|
|
#include <iterator>
|
|
|
|
#include <limits>
|
|
|
|
#include <map>
|
2014-03-09 19:36:40 +08:00
|
|
|
#include <memory>
|
2018-09-05 17:45:27 +08:00
|
|
|
#include <mutex>
|
2018-03-29 06:09:09 +08:00
|
|
|
#include <string>
|
|
|
|
#include <system_error>
|
2016-05-27 22:27:13 +08:00
|
|
|
#include <utility>
|
2018-03-29 06:09:09 +08:00
|
|
|
#include <vector>
|
2014-02-21 05:59:23 +08:00
|
|
|
|
|
|
|
using namespace llvm;
|
2018-10-10 21:27:25 +08:00
|
|
|
using namespace llvm::vfs;
|
2018-03-29 06:09:09 +08:00
|
|
|
|
[Support] Move llvm::MemoryBuffer to sys::fs::file_t
Summary:
On Windows, Posix integer file descriptors are a compatibility layer
over native file handles provided by the C runtime. There is a hard
limit on the maximum number of file descriptors that a process can open,
and the limit is 8192. LLD typically doesn't run into this limit because
it opens input files, maps them into memory, and then immediately closes
the file descriptor. This prevents it from running out of FDs.
For various reasons, I'd like to open handles to every input file and
keep them open during linking. That requires migrating MemoryBuffer over
to taking open native file handles instead of integer FDs.
Reviewers: aganea, Bigcheese
Reviewed By: aganea
Subscribers: smeenai, silvas, mehdi_amini, hiraditya, steven_wu, dexonsmith, dang, llvm-commits, zturner
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D63453
llvm-svn: 365588
2019-07-10 08:34:13 +08:00
|
|
|
using llvm::sys::fs::file_t;
|
2014-02-21 05:59:23 +08:00
|
|
|
using llvm::sys::fs::file_status;
|
|
|
|
using llvm::sys::fs::file_type;
|
[Support] Move llvm::MemoryBuffer to sys::fs::file_t
Summary:
On Windows, Posix integer file descriptors are a compatibility layer
over native file handles provided by the C runtime. There is a hard
limit on the maximum number of file descriptors that a process can open,
and the limit is 8192. LLD typically doesn't run into this limit because
it opens input files, maps them into memory, and then immediately closes
the file descriptor. This prevents it from running out of FDs.
For various reasons, I'd like to open handles to every input file and
keep them open during linking. That requires migrating MemoryBuffer over
to taking open native file handles instead of integer FDs.
Reviewers: aganea, Bigcheese
Reviewed By: aganea
Subscribers: smeenai, silvas, mehdi_amini, hiraditya, steven_wu, dexonsmith, dang, llvm-commits, zturner
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D63453
llvm-svn: 365588
2019-07-10 08:34:13 +08:00
|
|
|
using llvm::sys::fs::kInvalidFile;
|
2014-02-21 05:59:23 +08:00
|
|
|
using llvm::sys::fs::perms;
|
|
|
|
using llvm::sys::fs::UniqueID;
|
|
|
|
|
|
|
|
Status::Status(const file_status &Status)
|
|
|
|
: UID(Status.getUniqueID()), MTime(Status.getLastModificationTime()),
|
|
|
|
User(Status.getUser()), Group(Status.getGroup()), Size(Status.getSize()),
|
2018-10-10 21:27:25 +08:00
|
|
|
Type(Status.type()), Perms(Status.permissions()) {}
|
2014-02-21 05:59:23 +08:00
|
|
|
|
2019-02-24 07:48:47 +08:00
|
|
|
Status::Status(const Twine &Name, UniqueID UID, sys::TimePoint<> MTime,
|
2015-10-05 21:15:33 +08:00
|
|
|
uint32_t User, uint32_t Group, uint64_t Size, file_type Type,
|
|
|
|
perms Perms)
|
2019-02-24 07:48:47 +08:00
|
|
|
: Name(Name.str()), UID(UID), MTime(MTime), User(User), Group(Group),
|
|
|
|
Size(Size), Type(Type), Perms(Perms) {}
|
2014-02-21 05:59:23 +08:00
|
|
|
|
2019-02-24 07:48:47 +08:00
|
|
|
Status Status::copyWithNewName(const Status &In, const Twine &NewName) {
|
2018-07-25 04:28:07 +08:00
|
|
|
return Status(NewName, In.getUniqueID(), In.getLastModificationTime(),
|
|
|
|
In.getUser(), In.getGroup(), In.getSize(), In.getType(),
|
|
|
|
In.getPermissions());
|
|
|
|
}
|
|
|
|
|
2019-02-24 07:48:47 +08:00
|
|
|
Status Status::copyWithNewName(const file_status &In, const Twine &NewName) {
|
2018-07-25 04:28:07 +08:00
|
|
|
return Status(NewName, In.getUniqueID(), In.getLastModificationTime(),
|
|
|
|
In.getUser(), In.getGroup(), In.getSize(), In.type(),
|
|
|
|
In.permissions());
|
2015-10-05 21:15:33 +08:00
|
|
|
}
|
|
|
|
|
2014-02-21 05:59:23 +08:00
|
|
|
bool Status::equivalent(const Status &Other) const {
|
2017-07-20 19:57:02 +08:00
|
|
|
assert(isStatusKnown() && Other.isStatusKnown());
|
2014-02-21 05:59:23 +08:00
|
|
|
return getUniqueID() == Other.getUniqueID();
|
|
|
|
}
|
2018-03-29 06:09:09 +08:00
|
|
|
|
2018-10-10 21:27:25 +08:00
|
|
|
bool Status::isDirectory() const { return Type == file_type::directory_file; }
|
2018-03-29 06:09:09 +08:00
|
|
|
|
2018-10-10 21:27:25 +08:00
|
|
|
bool Status::isRegularFile() const { return Type == file_type::regular_file; }
|
2018-03-29 06:09:09 +08:00
|
|
|
|
2014-02-21 05:59:23 +08:00
|
|
|
bool Status::isOther() const {
|
|
|
|
return exists() && !isRegularFile() && !isDirectory() && !isSymlink();
|
|
|
|
}
|
2018-03-29 06:09:09 +08:00
|
|
|
|
2018-10-10 21:27:25 +08:00
|
|
|
bool Status::isSymlink() const { return Type == file_type::symlink_file; }
|
2018-03-29 06:09:09 +08:00
|
|
|
|
2018-10-10 21:27:25 +08:00
|
|
|
bool Status::isStatusKnown() const { return Type != file_type::status_error; }
|
2018-03-29 06:09:09 +08:00
|
|
|
|
2014-02-21 05:59:23 +08:00
|
|
|
bool Status::exists() const {
|
|
|
|
return isStatusKnown() && Type != file_type::file_not_found;
|
|
|
|
}
|
|
|
|
|
2018-03-29 06:09:09 +08:00
|
|
|
File::~File() = default;
|
2014-02-21 05:59:23 +08:00
|
|
|
|
2018-03-29 06:09:09 +08:00
|
|
|
FileSystem::~FileSystem() = default;
|
2014-02-21 05:59:23 +08:00
|
|
|
|
2014-10-27 06:44:13 +08:00
|
|
|
ErrorOr<std::unique_ptr<MemoryBuffer>>
|
|
|
|
FileSystem::getBufferForFile(const llvm::Twine &Name, int64_t FileSize,
|
|
|
|
bool RequiresNullTerminator, bool IsVolatile) {
|
|
|
|
auto F = openFileForRead(Name);
|
|
|
|
if (!F)
|
|
|
|
return F.getError();
|
|
|
|
|
|
|
|
return (*F)->getBuffer(Name, FileSize, RequiresNullTerminator, IsVolatile);
|
2014-02-21 05:59:23 +08:00
|
|
|
}
|
|
|
|
|
2015-10-05 21:55:20 +08:00
|
|
|
std::error_code FileSystem::makeAbsolute(SmallVectorImpl<char> &Path) const {
|
2016-03-27 02:55:13 +08:00
|
|
|
if (llvm::sys::path::is_absolute(Path))
|
2018-03-29 06:09:09 +08:00
|
|
|
return {};
|
2016-03-27 02:55:13 +08:00
|
|
|
|
2015-10-05 21:55:20 +08:00
|
|
|
auto WorkingDir = getCurrentWorkingDirectory();
|
|
|
|
if (!WorkingDir)
|
|
|
|
return WorkingDir.getError();
|
|
|
|
|
2019-01-16 17:55:32 +08:00
|
|
|
llvm::sys::fs::make_absolute(WorkingDir.get(), Path);
|
|
|
|
return {};
|
2015-10-05 21:55:20 +08:00
|
|
|
}
|
|
|
|
|
2018-05-17 18:26:23 +08:00
|
|
|
std::error_code FileSystem::getRealPath(const Twine &Path,
|
2018-11-09 23:11:34 +08:00
|
|
|
SmallVectorImpl<char> &Output) const {
|
2018-05-17 18:26:23 +08:00
|
|
|
return errc::operation_not_permitted;
|
|
|
|
}
|
|
|
|
|
2018-11-08 08:01:32 +08:00
|
|
|
std::error_code FileSystem::isLocal(const Twine &Path, bool &Result) {
|
|
|
|
return errc::operation_not_permitted;
|
|
|
|
}
|
|
|
|
|
2015-10-07 23:48:01 +08:00
|
|
|
bool FileSystem::exists(const Twine &Path) {
|
|
|
|
auto Status = status(Path);
|
|
|
|
return Status && Status->exists();
|
|
|
|
}
|
|
|
|
|
2016-03-17 10:20:43 +08:00
|
|
|
#ifndef NDEBUG
|
|
|
|
static bool isTraversalComponent(StringRef Component) {
|
|
|
|
return Component.equals("..") || Component.equals(".");
|
|
|
|
}
|
|
|
|
|
|
|
|
static bool pathHasTraversal(StringRef Path) {
|
|
|
|
using namespace llvm::sys;
|
2018-03-29 06:09:09 +08:00
|
|
|
|
2016-03-17 10:20:43 +08:00
|
|
|
for (StringRef Comp : llvm::make_range(path::begin(Path), path::end(Path)))
|
|
|
|
if (isTraversalComponent(Comp))
|
|
|
|
return true;
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
#endif
|
|
|
|
|
2014-02-21 05:59:23 +08:00
|
|
|
//===-----------------------------------------------------------------------===/
|
|
|
|
// RealFileSystem implementation
|
|
|
|
//===-----------------------------------------------------------------------===/
|
|
|
|
|
2014-03-02 01:21:22 +08:00
|
|
|
namespace {
|
2018-03-29 06:09:09 +08:00
|
|
|
|
2018-05-09 09:00:01 +08:00
|
|
|
/// Wrapper around a raw file descriptor.
|
2014-02-21 05:59:23 +08:00
|
|
|
class RealFile : public File {
|
2018-03-29 06:09:09 +08:00
|
|
|
friend class RealFileSystem;
|
|
|
|
|
[Support] Move llvm::MemoryBuffer to sys::fs::file_t
Summary:
On Windows, Posix integer file descriptors are a compatibility layer
over native file handles provided by the C runtime. There is a hard
limit on the maximum number of file descriptors that a process can open,
and the limit is 8192. LLD typically doesn't run into this limit because
it opens input files, maps them into memory, and then immediately closes
the file descriptor. This prevents it from running out of FDs.
For various reasons, I'd like to open handles to every input file and
keep them open during linking. That requires migrating MemoryBuffer over
to taking open native file handles instead of integer FDs.
Reviewers: aganea, Bigcheese
Reviewed By: aganea
Subscribers: smeenai, silvas, mehdi_amini, hiraditya, steven_wu, dexonsmith, dang, llvm-commits, zturner
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D63453
llvm-svn: 365588
2019-07-10 08:34:13 +08:00
|
|
|
file_t FD;
|
2014-03-01 05:16:07 +08:00
|
|
|
Status S;
|
2016-06-14 04:40:21 +08:00
|
|
|
std::string RealName;
|
2018-03-29 06:09:09 +08:00
|
|
|
|
2019-10-16 19:16:59 +08:00
|
|
|
RealFile(file_t RawFD, StringRef NewName, StringRef NewRealPathName)
|
|
|
|
: FD(RawFD), S(NewName, {}, {}, {}, {}, {},
|
|
|
|
llvm::sys::fs::file_type::status_error, {}),
|
2016-06-14 04:40:21 +08:00
|
|
|
RealName(NewRealPathName.str()) {
|
[Support] Move llvm::MemoryBuffer to sys::fs::file_t
Summary:
On Windows, Posix integer file descriptors are a compatibility layer
over native file handles provided by the C runtime. There is a hard
limit on the maximum number of file descriptors that a process can open,
and the limit is 8192. LLD typically doesn't run into this limit because
it opens input files, maps them into memory, and then immediately closes
the file descriptor. This prevents it from running out of FDs.
For various reasons, I'd like to open handles to every input file and
keep them open during linking. That requires migrating MemoryBuffer over
to taking open native file handles instead of integer FDs.
Reviewers: aganea, Bigcheese
Reviewed By: aganea
Subscribers: smeenai, silvas, mehdi_amini, hiraditya, steven_wu, dexonsmith, dang, llvm-commits, zturner
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D63453
llvm-svn: 365588
2019-07-10 08:34:13 +08:00
|
|
|
assert(FD != kInvalidFile && "Invalid or inactive file descriptor");
|
2014-02-21 05:59:23 +08:00
|
|
|
}
|
2014-02-22 07:39:37 +08:00
|
|
|
|
2014-02-21 05:59:23 +08:00
|
|
|
public:
|
2015-04-11 10:00:23 +08:00
|
|
|
~RealFile() override;
|
2018-03-29 06:09:09 +08:00
|
|
|
|
2014-03-02 17:32:10 +08:00
|
|
|
ErrorOr<Status> status() override;
|
2018-07-25 04:28:07 +08:00
|
|
|
ErrorOr<std::string> getName() override;
|
2015-10-06 05:20:19 +08:00
|
|
|
ErrorOr<std::unique_ptr<MemoryBuffer>> getBuffer(const Twine &Name,
|
|
|
|
int64_t FileSize,
|
|
|
|
bool RequiresNullTerminator,
|
|
|
|
bool IsVolatile) override;
|
2014-06-13 04:37:59 +08:00
|
|
|
std::error_code close() override;
|
2014-02-21 05:59:23 +08:00
|
|
|
};
|
2018-03-29 06:09:09 +08:00
|
|
|
|
|
|
|
} // namespace
|
|
|
|
|
2014-02-22 07:39:37 +08:00
|
|
|
RealFile::~RealFile() { close(); }
|
2014-02-21 05:59:23 +08:00
|
|
|
|
|
|
|
ErrorOr<Status> RealFile::status() {
|
[Support] Move llvm::MemoryBuffer to sys::fs::file_t
Summary:
On Windows, Posix integer file descriptors are a compatibility layer
over native file handles provided by the C runtime. There is a hard
limit on the maximum number of file descriptors that a process can open,
and the limit is 8192. LLD typically doesn't run into this limit because
it opens input files, maps them into memory, and then immediately closes
the file descriptor. This prevents it from running out of FDs.
For various reasons, I'd like to open handles to every input file and
keep them open during linking. That requires migrating MemoryBuffer over
to taking open native file handles instead of integer FDs.
Reviewers: aganea, Bigcheese
Reviewed By: aganea
Subscribers: smeenai, silvas, mehdi_amini, hiraditya, steven_wu, dexonsmith, dang, llvm-commits, zturner
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D63453
llvm-svn: 365588
2019-07-10 08:34:13 +08:00
|
|
|
assert(FD != kInvalidFile && "cannot stat closed file");
|
2014-03-01 05:16:07 +08:00
|
|
|
if (!S.isStatusKnown()) {
|
|
|
|
file_status RealStatus;
|
2014-06-13 04:37:59 +08:00
|
|
|
if (std::error_code EC = sys::fs::status(FD, RealStatus))
|
2014-03-01 05:16:07 +08:00
|
|
|
return EC;
|
2018-07-25 04:28:07 +08:00
|
|
|
S = Status::copyWithNewName(RealStatus, S.getName());
|
2014-03-01 05:16:07 +08:00
|
|
|
}
|
|
|
|
return S;
|
2014-02-21 05:59:23 +08:00
|
|
|
}
|
|
|
|
|
2018-07-25 04:28:07 +08:00
|
|
|
ErrorOr<std::string> RealFile::getName() {
|
|
|
|
return RealName.empty() ? S.getName().str() : RealName;
|
2016-06-14 04:40:21 +08:00
|
|
|
}
|
|
|
|
|
2014-10-27 06:44:13 +08:00
|
|
|
ErrorOr<std::unique_ptr<MemoryBuffer>>
|
|
|
|
RealFile::getBuffer(const Twine &Name, int64_t FileSize,
|
|
|
|
bool RequiresNullTerminator, bool IsVolatile) {
|
[Support] Move llvm::MemoryBuffer to sys::fs::file_t
Summary:
On Windows, Posix integer file descriptors are a compatibility layer
over native file handles provided by the C runtime. There is a hard
limit on the maximum number of file descriptors that a process can open,
and the limit is 8192. LLD typically doesn't run into this limit because
it opens input files, maps them into memory, and then immediately closes
the file descriptor. This prevents it from running out of FDs.
For various reasons, I'd like to open handles to every input file and
keep them open during linking. That requires migrating MemoryBuffer over
to taking open native file handles instead of integer FDs.
Reviewers: aganea, Bigcheese
Reviewed By: aganea
Subscribers: smeenai, silvas, mehdi_amini, hiraditya, steven_wu, dexonsmith, dang, llvm-commits, zturner
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D63453
llvm-svn: 365588
2019-07-10 08:34:13 +08:00
|
|
|
assert(FD != kInvalidFile && "cannot get buffer for closed file");
|
2014-10-27 06:44:13 +08:00
|
|
|
return MemoryBuffer::getOpenFile(FD, Name, FileSize, RequiresNullTerminator,
|
|
|
|
IsVolatile);
|
2014-02-21 05:59:23 +08:00
|
|
|
}
|
|
|
|
|
2014-06-13 04:37:59 +08:00
|
|
|
std::error_code RealFile::close() {
|
[Support] Move llvm::MemoryBuffer to sys::fs::file_t
Summary:
On Windows, Posix integer file descriptors are a compatibility layer
over native file handles provided by the C runtime. There is a hard
limit on the maximum number of file descriptors that a process can open,
and the limit is 8192. LLD typically doesn't run into this limit because
it opens input files, maps them into memory, and then immediately closes
the file descriptor. This prevents it from running out of FDs.
For various reasons, I'd like to open handles to every input file and
keep them open during linking. That requires migrating MemoryBuffer over
to taking open native file handles instead of integer FDs.
Reviewers: aganea, Bigcheese
Reviewed By: aganea
Subscribers: smeenai, silvas, mehdi_amini, hiraditya, steven_wu, dexonsmith, dang, llvm-commits, zturner
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D63453
llvm-svn: 365588
2019-07-10 08:34:13 +08:00
|
|
|
std::error_code EC = sys::fs::closeFile(FD);
|
|
|
|
FD = kInvalidFile;
|
2016-03-04 13:26:14 +08:00
|
|
|
return EC;
|
2014-02-21 05:59:23 +08:00
|
|
|
}
|
|
|
|
|
2014-03-02 01:21:22 +08:00
|
|
|
namespace {
|
2018-03-29 06:09:09 +08:00
|
|
|
|
2019-02-14 20:57:01 +08:00
|
|
|
/// A file system according to your operating system.
|
|
|
|
/// This may be linked to the process's working directory, or maintain its own.
|
|
|
|
///
|
|
|
|
/// Currently, its own working directory is emulated by storing the path and
|
|
|
|
/// sending absolute paths to llvm::sys::fs:: functions.
|
|
|
|
/// A more principled approach would be to push this down a level, modelling
|
|
|
|
/// the working dir as an llvm::sys::fs::WorkingDir or similar.
|
|
|
|
/// This would enable the use of openat()-style functions on some platforms.
|
2014-02-21 05:59:23 +08:00
|
|
|
class RealFileSystem : public FileSystem {
|
|
|
|
public:
|
2019-02-14 20:57:01 +08:00
|
|
|
explicit RealFileSystem(bool LinkCWDToProcess) {
|
|
|
|
if (!LinkCWDToProcess) {
|
|
|
|
SmallString<128> PWD, RealPWD;
|
|
|
|
if (llvm::sys::fs::current_path(PWD))
|
|
|
|
return; // Awful, but nothing to do here.
|
|
|
|
if (llvm::sys::fs::real_path(PWD, RealPWD))
|
|
|
|
WD = {PWD, PWD};
|
|
|
|
else
|
|
|
|
WD = {PWD, RealPWD};
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2014-03-02 17:32:10 +08:00
|
|
|
ErrorOr<Status> status(const Twine &Path) override;
|
2014-10-27 06:44:13 +08:00
|
|
|
ErrorOr<std::unique_ptr<File>> openFileForRead(const Twine &Path) override;
|
2014-06-25 03:37:16 +08:00
|
|
|
directory_iterator dir_begin(const Twine &Dir, std::error_code &EC) override;
|
2015-10-05 21:55:20 +08:00
|
|
|
|
|
|
|
llvm::ErrorOr<std::string> getCurrentWorkingDirectory() const override;
|
|
|
|
std::error_code setCurrentWorkingDirectory(const Twine &Path) override;
|
2018-11-08 08:01:32 +08:00
|
|
|
std::error_code isLocal(const Twine &Path, bool &Result) override;
|
2018-11-09 23:11:34 +08:00
|
|
|
std::error_code getRealPath(const Twine &Path,
|
|
|
|
SmallVectorImpl<char> &Output) const override;
|
2018-10-10 21:27:25 +08:00
|
|
|
|
2018-09-05 17:45:27 +08:00
|
|
|
private:
|
2019-02-14 20:57:01 +08:00
|
|
|
// If this FS has its own working dir, use it to make Path absolute.
|
|
|
|
// The returned twine is safe to use as long as both Storage and Path live.
|
|
|
|
Twine adjustPath(const Twine &Path, SmallVectorImpl<char> &Storage) const {
|
|
|
|
if (!WD)
|
|
|
|
return Path;
|
|
|
|
Path.toVector(Storage);
|
|
|
|
sys::fs::make_absolute(WD->Resolved, Storage);
|
|
|
|
return Storage;
|
|
|
|
}
|
|
|
|
|
|
|
|
struct WorkingDirectory {
|
|
|
|
// The current working directory, without symlinks resolved. (echo $PWD).
|
|
|
|
SmallString<128> Specified;
|
|
|
|
// The current working directory, with links resolved. (readlink .).
|
|
|
|
SmallString<128> Resolved;
|
|
|
|
};
|
|
|
|
Optional<WorkingDirectory> WD;
|
2014-02-21 05:59:23 +08:00
|
|
|
};
|
2018-03-29 06:09:09 +08:00
|
|
|
|
|
|
|
} // namespace
|
2014-02-21 05:59:23 +08:00
|
|
|
|
|
|
|
ErrorOr<Status> RealFileSystem::status(const Twine &Path) {
|
2019-02-14 20:57:01 +08:00
|
|
|
SmallString<256> Storage;
|
2014-02-21 05:59:23 +08:00
|
|
|
sys::fs::file_status RealStatus;
|
2019-02-14 20:57:01 +08:00
|
|
|
if (std::error_code EC =
|
|
|
|
sys::fs::status(adjustPath(Path, Storage), RealStatus))
|
2014-02-21 05:59:23 +08:00
|
|
|
return EC;
|
2019-02-24 07:48:47 +08:00
|
|
|
return Status::copyWithNewName(RealStatus, Path);
|
2014-02-21 05:59:23 +08:00
|
|
|
}
|
|
|
|
|
2014-10-27 06:44:13 +08:00
|
|
|
ErrorOr<std::unique_ptr<File>>
|
|
|
|
RealFileSystem::openFileForRead(const Twine &Name) {
|
2019-02-14 20:57:01 +08:00
|
|
|
SmallString<256> RealName, Storage;
|
[Support] Move llvm::MemoryBuffer to sys::fs::file_t
Summary:
On Windows, Posix integer file descriptors are a compatibility layer
over native file handles provided by the C runtime. There is a hard
limit on the maximum number of file descriptors that a process can open,
and the limit is 8192. LLD typically doesn't run into this limit because
it opens input files, maps them into memory, and then immediately closes
the file descriptor. This prevents it from running out of FDs.
For various reasons, I'd like to open handles to every input file and
keep them open during linking. That requires migrating MemoryBuffer over
to taking open native file handles instead of integer FDs.
Reviewers: aganea, Bigcheese
Reviewed By: aganea
Subscribers: smeenai, silvas, mehdi_amini, hiraditya, steven_wu, dexonsmith, dang, llvm-commits, zturner
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D63453
llvm-svn: 365588
2019-07-10 08:34:13 +08:00
|
|
|
Expected<file_t> FDOrErr = sys::fs::openNativeFileForRead(
|
|
|
|
adjustPath(Name, Storage), sys::fs::OF_None, &RealName);
|
|
|
|
if (!FDOrErr)
|
|
|
|
return errorToErrorCode(FDOrErr.takeError());
|
|
|
|
return std::unique_ptr<File>(
|
|
|
|
new RealFile(*FDOrErr, Name.str(), RealName.str()));
|
2014-02-21 05:59:23 +08:00
|
|
|
}
|
|
|
|
|
2015-10-05 21:55:20 +08:00
|
|
|
llvm::ErrorOr<std::string> RealFileSystem::getCurrentWorkingDirectory() const {
|
2019-02-14 20:57:01 +08:00
|
|
|
if (WD)
|
2020-01-29 03:23:46 +08:00
|
|
|
return std::string(WD->Specified.str());
|
2019-02-14 20:57:01 +08:00
|
|
|
|
|
|
|
SmallString<128> Dir;
|
2015-10-05 21:55:20 +08:00
|
|
|
if (std::error_code EC = llvm::sys::fs::current_path(Dir))
|
|
|
|
return EC;
|
2020-01-29 03:23:46 +08:00
|
|
|
return std::string(Dir.str());
|
2015-10-05 21:55:20 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
std::error_code RealFileSystem::setCurrentWorkingDirectory(const Twine &Path) {
|
2019-02-14 20:57:01 +08:00
|
|
|
if (!WD)
|
|
|
|
return llvm::sys::fs::set_current_path(Path);
|
|
|
|
|
|
|
|
SmallString<128> Absolute, Resolved, Storage;
|
|
|
|
adjustPath(Path, Storage).toVector(Absolute);
|
|
|
|
bool IsDir;
|
|
|
|
if (auto Err = llvm::sys::fs::is_directory(Absolute, IsDir))
|
|
|
|
return Err;
|
|
|
|
if (!IsDir)
|
|
|
|
return std::make_error_code(std::errc::not_a_directory);
|
|
|
|
if (auto Err = llvm::sys::fs::real_path(Absolute, Resolved))
|
|
|
|
return Err;
|
|
|
|
WD = {Absolute, Resolved};
|
2018-09-05 17:45:27 +08:00
|
|
|
return std::error_code();
|
2015-10-05 21:55:20 +08:00
|
|
|
}
|
|
|
|
|
2018-11-08 08:01:32 +08:00
|
|
|
std::error_code RealFileSystem::isLocal(const Twine &Path, bool &Result) {
|
2019-02-14 20:57:01 +08:00
|
|
|
SmallString<256> Storage;
|
|
|
|
return llvm::sys::fs::is_local(adjustPath(Path, Storage), Result);
|
2018-11-08 08:01:32 +08:00
|
|
|
}
|
|
|
|
|
2018-11-09 23:11:34 +08:00
|
|
|
std::error_code
|
|
|
|
RealFileSystem::getRealPath(const Twine &Path,
|
|
|
|
SmallVectorImpl<char> &Output) const {
|
2019-02-14 20:57:01 +08:00
|
|
|
SmallString<256> Storage;
|
|
|
|
return llvm::sys::fs::real_path(adjustPath(Path, Storage), Output);
|
2018-05-17 18:26:23 +08:00
|
|
|
}
|
|
|
|
|
2014-02-21 05:59:23 +08:00
|
|
|
IntrusiveRefCntPtr<FileSystem> vfs::getRealFileSystem() {
|
2019-02-14 20:57:01 +08:00
|
|
|
static IntrusiveRefCntPtr<FileSystem> FS(new RealFileSystem(true));
|
2014-02-21 05:59:23 +08:00
|
|
|
return FS;
|
|
|
|
}
|
|
|
|
|
2019-02-14 20:57:01 +08:00
|
|
|
std::unique_ptr<FileSystem> vfs::createPhysicalFileSystem() {
|
2019-08-15 23:54:37 +08:00
|
|
|
return std::make_unique<RealFileSystem>(false);
|
2019-02-14 20:57:01 +08:00
|
|
|
}
|
|
|
|
|
2014-06-25 03:37:16 +08:00
|
|
|
namespace {
|
2018-03-29 06:09:09 +08:00
|
|
|
|
2018-10-10 21:27:25 +08:00
|
|
|
class RealFSDirIter : public llvm::vfs::detail::DirIterImpl {
|
2014-06-25 03:37:16 +08:00
|
|
|
llvm::sys::fs::directory_iterator Iter;
|
2018-03-29 06:09:09 +08:00
|
|
|
|
2014-06-25 03:37:16 +08:00
|
|
|
public:
|
2017-03-11 05:23:29 +08:00
|
|
|
RealFSDirIter(const Twine &Path, std::error_code &EC) : Iter(Path, EC) {
|
2018-09-14 20:47:38 +08:00
|
|
|
if (Iter != llvm::sys::fs::directory_iterator())
|
|
|
|
CurrentEntry = directory_entry(Iter->path(), Iter->type());
|
2014-06-25 03:37:16 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
std::error_code increment() override {
|
|
|
|
std::error_code EC;
|
|
|
|
Iter.increment(EC);
|
2018-09-14 20:47:38 +08:00
|
|
|
CurrentEntry = (Iter == llvm::sys::fs::directory_iterator())
|
|
|
|
? directory_entry()
|
|
|
|
: directory_entry(Iter->path(), Iter->type());
|
2014-06-25 03:37:16 +08:00
|
|
|
return EC;
|
|
|
|
}
|
|
|
|
};
|
2018-03-29 06:09:09 +08:00
|
|
|
|
|
|
|
} // namespace
|
2014-06-25 03:37:16 +08:00
|
|
|
|
|
|
|
directory_iterator RealFileSystem::dir_begin(const Twine &Dir,
|
|
|
|
std::error_code &EC) {
|
2019-02-14 20:57:01 +08:00
|
|
|
SmallString<128> Storage;
|
|
|
|
return directory_iterator(
|
|
|
|
std::make_shared<RealFSDirIter>(adjustPath(Dir, Storage), EC));
|
2014-06-25 03:37:16 +08:00
|
|
|
}
|
|
|
|
|
2014-02-21 05:59:23 +08:00
|
|
|
//===-----------------------------------------------------------------------===/
|
|
|
|
// OverlayFileSystem implementation
|
|
|
|
//===-----------------------------------------------------------------------===/
|
2018-03-29 06:09:09 +08:00
|
|
|
|
2014-02-21 05:59:23 +08:00
|
|
|
OverlayFileSystem::OverlayFileSystem(IntrusiveRefCntPtr<FileSystem> BaseFS) {
|
2016-06-13 04:05:23 +08:00
|
|
|
FSList.push_back(std::move(BaseFS));
|
2014-02-21 05:59:23 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
void OverlayFileSystem::pushOverlay(IntrusiveRefCntPtr<FileSystem> FS) {
|
|
|
|
FSList.push_back(FS);
|
2015-10-05 21:55:20 +08:00
|
|
|
// Synchronize added file systems by duplicating the working directory from
|
|
|
|
// the first one in the list.
|
|
|
|
FS->setCurrentWorkingDirectory(getCurrentWorkingDirectory().get());
|
2014-02-21 05:59:23 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
ErrorOr<Status> OverlayFileSystem::status(const Twine &Path) {
|
|
|
|
// FIXME: handle symlinks that cross file systems
|
|
|
|
for (iterator I = overlays_begin(), E = overlays_end(); I != E; ++I) {
|
|
|
|
ErrorOr<Status> Status = (*I)->status(Path);
|
2014-06-14 01:20:50 +08:00
|
|
|
if (Status || Status.getError() != llvm::errc::no_such_file_or_directory)
|
2014-02-21 05:59:23 +08:00
|
|
|
return Status;
|
|
|
|
}
|
2014-06-14 01:20:50 +08:00
|
|
|
return make_error_code(llvm::errc::no_such_file_or_directory);
|
2014-02-21 05:59:23 +08:00
|
|
|
}
|
|
|
|
|
2014-10-27 06:44:13 +08:00
|
|
|
ErrorOr<std::unique_ptr<File>>
|
|
|
|
OverlayFileSystem::openFileForRead(const llvm::Twine &Path) {
|
2014-02-21 05:59:23 +08:00
|
|
|
// FIXME: handle symlinks that cross file systems
|
|
|
|
for (iterator I = overlays_begin(), E = overlays_end(); I != E; ++I) {
|
2014-10-27 06:44:13 +08:00
|
|
|
auto Result = (*I)->openFileForRead(Path);
|
|
|
|
if (Result || Result.getError() != llvm::errc::no_such_file_or_directory)
|
|
|
|
return Result;
|
2014-02-21 05:59:23 +08:00
|
|
|
}
|
2014-06-14 01:20:50 +08:00
|
|
|
return make_error_code(llvm::errc::no_such_file_or_directory);
|
2014-02-21 05:59:23 +08:00
|
|
|
}
|
2014-02-22 07:39:37 +08:00
|
|
|
|
2015-10-05 21:55:20 +08:00
|
|
|
llvm::ErrorOr<std::string>
|
|
|
|
OverlayFileSystem::getCurrentWorkingDirectory() const {
|
|
|
|
// All file systems are synchronized, just take the first working directory.
|
|
|
|
return FSList.front()->getCurrentWorkingDirectory();
|
|
|
|
}
|
2018-03-29 06:09:09 +08:00
|
|
|
|
2015-10-05 21:55:20 +08:00
|
|
|
std::error_code
|
|
|
|
OverlayFileSystem::setCurrentWorkingDirectory(const Twine &Path) {
|
|
|
|
for (auto &FS : FSList)
|
|
|
|
if (std::error_code EC = FS->setCurrentWorkingDirectory(Path))
|
|
|
|
return EC;
|
2018-03-29 06:09:09 +08:00
|
|
|
return {};
|
2015-10-05 21:55:20 +08:00
|
|
|
}
|
|
|
|
|
2018-11-08 08:01:32 +08:00
|
|
|
std::error_code OverlayFileSystem::isLocal(const Twine &Path, bool &Result) {
|
|
|
|
for (auto &FS : FSList)
|
|
|
|
if (FS->exists(Path))
|
|
|
|
return FS->isLocal(Path, Result);
|
|
|
|
return errc::no_such_file_or_directory;
|
|
|
|
}
|
|
|
|
|
2018-11-09 23:11:34 +08:00
|
|
|
std::error_code
|
|
|
|
OverlayFileSystem::getRealPath(const Twine &Path,
|
|
|
|
SmallVectorImpl<char> &Output) const {
|
2018-05-18 21:22:49 +08:00
|
|
|
for (auto &FS : FSList)
|
|
|
|
if (FS->exists(Path))
|
2018-11-09 23:11:34 +08:00
|
|
|
return FS->getRealPath(Path, Output);
|
2018-05-18 21:22:49 +08:00
|
|
|
return errc::no_such_file_or_directory;
|
|
|
|
}
|
|
|
|
|
2018-10-10 21:27:25 +08:00
|
|
|
llvm::vfs::detail::DirIterImpl::~DirIterImpl() = default;
|
2014-06-25 03:37:16 +08:00
|
|
|
|
|
|
|
namespace {
|
2018-03-29 06:09:09 +08:00
|
|
|
|
2018-10-10 21:27:25 +08:00
|
|
|
class OverlayFSDirIterImpl : public llvm::vfs::detail::DirIterImpl {
|
2014-06-25 03:37:16 +08:00
|
|
|
OverlayFileSystem &Overlays;
|
|
|
|
std::string Path;
|
|
|
|
OverlayFileSystem::iterator CurrentFS;
|
|
|
|
directory_iterator CurrentDirIter;
|
|
|
|
llvm::StringSet<> SeenNames;
|
|
|
|
|
|
|
|
std::error_code incrementFS() {
|
|
|
|
assert(CurrentFS != Overlays.overlays_end() && "incrementing past end");
|
|
|
|
++CurrentFS;
|
|
|
|
for (auto E = Overlays.overlays_end(); CurrentFS != E; ++CurrentFS) {
|
|
|
|
std::error_code EC;
|
|
|
|
CurrentDirIter = (*CurrentFS)->dir_begin(Path, EC);
|
|
|
|
if (EC && EC != errc::no_such_file_or_directory)
|
|
|
|
return EC;
|
|
|
|
if (CurrentDirIter != directory_iterator())
|
|
|
|
break; // found
|
|
|
|
}
|
2018-03-29 06:09:09 +08:00
|
|
|
return {};
|
2014-06-25 03:37:16 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
std::error_code incrementDirIter(bool IsFirstTime) {
|
|
|
|
assert((IsFirstTime || CurrentDirIter != directory_iterator()) &&
|
|
|
|
"incrementing past end");
|
|
|
|
std::error_code EC;
|
|
|
|
if (!IsFirstTime)
|
|
|
|
CurrentDirIter.increment(EC);
|
|
|
|
if (!EC && CurrentDirIter == directory_iterator())
|
|
|
|
EC = incrementFS();
|
|
|
|
return EC;
|
|
|
|
}
|
|
|
|
|
|
|
|
std::error_code incrementImpl(bool IsFirstTime) {
|
|
|
|
while (true) {
|
|
|
|
std::error_code EC = incrementDirIter(IsFirstTime);
|
|
|
|
if (EC || CurrentDirIter == directory_iterator()) {
|
2018-09-14 20:47:38 +08:00
|
|
|
CurrentEntry = directory_entry();
|
2014-06-25 03:37:16 +08:00
|
|
|
return EC;
|
|
|
|
}
|
|
|
|
CurrentEntry = *CurrentDirIter;
|
2018-09-14 20:47:38 +08:00
|
|
|
StringRef Name = llvm::sys::path::filename(CurrentEntry.path());
|
2014-11-19 10:56:13 +08:00
|
|
|
if (SeenNames.insert(Name).second)
|
2014-06-25 03:37:16 +08:00
|
|
|
return EC; // name not seen before
|
|
|
|
}
|
|
|
|
llvm_unreachable("returned above");
|
|
|
|
}
|
|
|
|
|
|
|
|
public:
|
|
|
|
OverlayFSDirIterImpl(const Twine &Path, OverlayFileSystem &FS,
|
|
|
|
std::error_code &EC)
|
|
|
|
: Overlays(FS), Path(Path.str()), CurrentFS(Overlays.overlays_begin()) {
|
|
|
|
CurrentDirIter = (*CurrentFS)->dir_begin(Path, EC);
|
|
|
|
EC = incrementImpl(true);
|
|
|
|
}
|
|
|
|
|
|
|
|
std::error_code increment() override { return incrementImpl(false); }
|
|
|
|
};
|
2018-03-29 06:09:09 +08:00
|
|
|
|
|
|
|
} // namespace
|
2014-06-25 03:37:16 +08:00
|
|
|
|
|
|
|
directory_iterator OverlayFileSystem::dir_begin(const Twine &Dir,
|
|
|
|
std::error_code &EC) {
|
|
|
|
return directory_iterator(
|
|
|
|
std::make_shared<OverlayFSDirIterImpl>(Dir, *this, EC));
|
|
|
|
}
|
|
|
|
|
2018-12-29 10:02:13 +08:00
|
|
|
void ProxyFileSystem::anchor() {}
|
|
|
|
|
2018-10-10 21:27:25 +08:00
|
|
|
namespace llvm {
|
2015-10-05 21:55:14 +08:00
|
|
|
namespace vfs {
|
2018-03-29 06:09:09 +08:00
|
|
|
|
2015-10-05 21:55:14 +08:00
|
|
|
namespace detail {
|
|
|
|
|
2018-09-04 22:15:53 +08:00
|
|
|
enum InMemoryNodeKind { IME_File, IME_Directory, IME_HardLink };
|
2015-10-05 21:55:14 +08:00
|
|
|
|
|
|
|
/// The in memory file system is a tree of Nodes. Every node can either be a
|
2018-09-04 22:15:53 +08:00
|
|
|
/// file , hardlink or a directory.
|
2015-10-05 21:55:14 +08:00
|
|
|
class InMemoryNode {
|
2018-07-12 02:43:07 +08:00
|
|
|
InMemoryNodeKind Kind;
|
2018-09-04 22:15:53 +08:00
|
|
|
std::string FileName;
|
[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
|
|
|
|
2015-10-05 21:55:14 +08:00
|
|
|
public:
|
2018-09-04 22:15:53 +08:00
|
|
|
InMemoryNode(llvm::StringRef FileName, InMemoryNodeKind Kind)
|
2020-01-29 03:23:46 +08:00
|
|
|
: Kind(Kind), FileName(std::string(llvm::sys::path::filename(FileName))) {
|
|
|
|
}
|
2018-03-29 06:09:09 +08:00
|
|
|
virtual ~InMemoryNode() = default;
|
|
|
|
|
2018-09-04 22:15:53 +08:00
|
|
|
/// Get the filename of this node (the name without the directory part).
|
|
|
|
StringRef getFileName() const { return FileName; }
|
|
|
|
InMemoryNodeKind getKind() const { return Kind; }
|
|
|
|
virtual std::string toString(unsigned Indent) const = 0;
|
|
|
|
};
|
|
|
|
|
|
|
|
class InMemoryFile : public InMemoryNode {
|
|
|
|
Status Stat;
|
|
|
|
std::unique_ptr<llvm::MemoryBuffer> Buffer;
|
|
|
|
|
|
|
|
public:
|
|
|
|
InMemoryFile(Status Stat, std::unique_ptr<llvm::MemoryBuffer> Buffer)
|
|
|
|
: InMemoryNode(Stat.getName(), IME_File), Stat(std::move(Stat)),
|
|
|
|
Buffer(std::move(Buffer)) {}
|
|
|
|
|
[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
|
|
|
/// Return the \p Status for this node. \p RequestedName should be the name
|
|
|
|
/// through which the caller referred to this node. It will override
|
|
|
|
/// \p Status::Name in the return value, to mimic the behavior of \p RealFile.
|
2019-02-24 07:48:47 +08:00
|
|
|
Status getStatus(const Twine &RequestedName) const {
|
[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
|
|
|
return Status::copyWithNewName(Stat, RequestedName);
|
|
|
|
}
|
2018-09-04 22:15:53 +08:00
|
|
|
llvm::MemoryBuffer *getBuffer() const { return Buffer.get(); }
|
[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
|
|
|
|
2018-09-04 22:15:53 +08:00
|
|
|
std::string toString(unsigned Indent) const override {
|
|
|
|
return (std::string(Indent, ' ') + Stat.getName() + "\n").str();
|
|
|
|
}
|
|
|
|
|
|
|
|
static bool classof(const InMemoryNode *N) {
|
|
|
|
return N->getKind() == IME_File;
|
[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
|
|
|
}
|
2015-10-05 21:55:14 +08:00
|
|
|
};
|
|
|
|
|
|
|
|
namespace {
|
2018-03-29 06:09:09 +08:00
|
|
|
|
2018-09-04 22:15:53 +08:00
|
|
|
class InMemoryHardLink : public InMemoryNode {
|
|
|
|
const InMemoryFile &ResolvedFile;
|
2015-10-05 21:55:14 +08:00
|
|
|
|
|
|
|
public:
|
2018-09-04 22:15:53 +08:00
|
|
|
InMemoryHardLink(StringRef Path, const InMemoryFile &ResolvedFile)
|
|
|
|
: InMemoryNode(Path, IME_HardLink), ResolvedFile(ResolvedFile) {}
|
|
|
|
const InMemoryFile &getResolvedFile() const { return ResolvedFile; }
|
2018-03-29 06:09:09 +08:00
|
|
|
|
2015-10-05 21:55:14 +08:00
|
|
|
std::string toString(unsigned Indent) const override {
|
2018-09-04 22:15:53 +08:00
|
|
|
return std::string(Indent, ' ') + "HardLink to -> " +
|
|
|
|
ResolvedFile.toString(0);
|
2015-10-05 21:55:14 +08:00
|
|
|
}
|
2018-03-29 06:09:09 +08:00
|
|
|
|
2015-10-05 21:55:14 +08:00
|
|
|
static bool classof(const InMemoryNode *N) {
|
2018-09-04 22:15:53 +08:00
|
|
|
return N->getKind() == IME_HardLink;
|
2015-10-05 21:55:14 +08:00
|
|
|
}
|
|
|
|
};
|
|
|
|
|
[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
|
|
|
/// Adapt a InMemoryFile for VFS' File interface. The goal is to make
|
|
|
|
/// \p InMemoryFileAdaptor mimic as much as possible the behavior of
|
|
|
|
/// \p RealFile.
|
2015-10-05 21:55:14 +08:00
|
|
|
class InMemoryFileAdaptor : public File {
|
2018-09-04 22:15:53 +08:00
|
|
|
const InMemoryFile &Node;
|
[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
|
|
|
/// The name to use when returning a Status for this file.
|
|
|
|
std::string RequestedName;
|
2015-10-05 21:55:14 +08:00
|
|
|
|
|
|
|
public:
|
2018-09-04 22:15:53 +08:00
|
|
|
explicit InMemoryFileAdaptor(const InMemoryFile &Node,
|
|
|
|
std::string RequestedName)
|
[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
|
|
|
: Node(Node), RequestedName(std::move(RequestedName)) {}
|
2015-10-05 21:55:14 +08:00
|
|
|
|
[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
|
|
|
llvm::ErrorOr<Status> status() override {
|
|
|
|
return Node.getStatus(RequestedName);
|
|
|
|
}
|
2018-03-29 06:09:09 +08:00
|
|
|
|
2015-10-05 21:55:14 +08:00
|
|
|
llvm::ErrorOr<std::unique_ptr<llvm::MemoryBuffer>>
|
2015-10-06 05:20:19 +08:00
|
|
|
getBuffer(const Twine &Name, int64_t FileSize, bool RequiresNullTerminator,
|
|
|
|
bool IsVolatile) override {
|
2015-10-05 21:55:14 +08:00
|
|
|
llvm::MemoryBuffer *Buf = Node.getBuffer();
|
|
|
|
return llvm::MemoryBuffer::getMemBuffer(
|
|
|
|
Buf->getBuffer(), Buf->getBufferIdentifier(), RequiresNullTerminator);
|
|
|
|
}
|
2018-03-29 06:09:09 +08:00
|
|
|
|
|
|
|
std::error_code close() override { return {}; }
|
2015-10-05 21:55:14 +08:00
|
|
|
};
|
2018-03-29 06:09:09 +08:00
|
|
|
} // namespace
|
2015-10-05 21:55:14 +08:00
|
|
|
|
|
|
|
class InMemoryDirectory : public InMemoryNode {
|
2018-09-04 22:15:53 +08:00
|
|
|
Status Stat;
|
2018-09-24 22:52:11 +08:00
|
|
|
llvm::StringMap<std::unique_ptr<InMemoryNode>> Entries;
|
2015-10-05 21:55:14 +08:00
|
|
|
|
|
|
|
public:
|
|
|
|
InMemoryDirectory(Status Stat)
|
2018-09-04 22:15:53 +08:00
|
|
|
: InMemoryNode(Stat.getName(), IME_Directory), Stat(std::move(Stat)) {}
|
2018-03-29 06:09:09 +08:00
|
|
|
|
2018-09-04 22:15:53 +08:00
|
|
|
/// Return the \p Status for this node. \p RequestedName should be the name
|
|
|
|
/// through which the caller referred to this node. It will override
|
|
|
|
/// \p Status::Name in the return value, to mimic the behavior of \p RealFile.
|
2019-02-24 07:48:47 +08:00
|
|
|
Status getStatus(const Twine &RequestedName) const {
|
2018-09-04 22:15:53 +08:00
|
|
|
return Status::copyWithNewName(Stat, RequestedName);
|
|
|
|
}
|
2015-10-05 21:55:14 +08:00
|
|
|
InMemoryNode *getChild(StringRef Name) {
|
|
|
|
auto I = Entries.find(Name);
|
|
|
|
if (I != Entries.end())
|
|
|
|
return I->second.get();
|
|
|
|
return nullptr;
|
|
|
|
}
|
2018-03-29 06:09:09 +08:00
|
|
|
|
2015-10-05 21:55:14 +08:00
|
|
|
InMemoryNode *addChild(StringRef Name, std::unique_ptr<InMemoryNode> Child) {
|
|
|
|
return Entries.insert(make_pair(Name, std::move(Child)))
|
|
|
|
.first->second.get();
|
|
|
|
}
|
|
|
|
|
2018-03-29 06:09:09 +08:00
|
|
|
using const_iterator = decltype(Entries)::const_iterator;
|
|
|
|
|
2015-10-05 21:55:14 +08:00
|
|
|
const_iterator begin() const { return Entries.begin(); }
|
|
|
|
const_iterator end() const { return Entries.end(); }
|
|
|
|
|
|
|
|
std::string toString(unsigned Indent) const override {
|
|
|
|
std::string Result =
|
2018-09-04 22:15:53 +08:00
|
|
|
(std::string(Indent, ' ') + Stat.getName() + "\n").str();
|
2018-03-29 06:09:09 +08:00
|
|
|
for (const auto &Entry : Entries)
|
2015-10-05 21:55:14 +08:00
|
|
|
Result += Entry.second->toString(Indent + 2);
|
|
|
|
return Result;
|
|
|
|
}
|
2018-03-29 06:09:09 +08:00
|
|
|
|
2015-10-05 21:55:14 +08:00
|
|
|
static bool classof(const InMemoryNode *N) {
|
|
|
|
return N->getKind() == IME_Directory;
|
|
|
|
}
|
|
|
|
};
|
2018-03-29 06:09:09 +08:00
|
|
|
|
2018-09-04 22:15:53 +08:00
|
|
|
namespace {
|
2019-02-24 07:48:47 +08:00
|
|
|
Status getNodeStatus(const InMemoryNode *Node, const Twine &RequestedName) {
|
2018-09-04 22:15:53 +08:00
|
|
|
if (auto Dir = dyn_cast<detail::InMemoryDirectory>(Node))
|
|
|
|
return Dir->getStatus(RequestedName);
|
|
|
|
if (auto File = dyn_cast<detail::InMemoryFile>(Node))
|
|
|
|
return File->getStatus(RequestedName);
|
|
|
|
if (auto Link = dyn_cast<detail::InMemoryHardLink>(Node))
|
|
|
|
return Link->getResolvedFile().getStatus(RequestedName);
|
|
|
|
llvm_unreachable("Unknown node type");
|
|
|
|
}
|
|
|
|
} // namespace
|
2018-03-29 06:09:09 +08:00
|
|
|
} // namespace detail
|
2015-10-05 21:55:14 +08:00
|
|
|
|
2015-10-13 00:16:39 +08:00
|
|
|
InMemoryFileSystem::InMemoryFileSystem(bool UseNormalizedPaths)
|
2015-10-05 21:55:14 +08:00
|
|
|
: Root(new detail::InMemoryDirectory(
|
2016-11-09 18:52:22 +08:00
|
|
|
Status("", getNextVirtualUniqueID(), llvm::sys::TimePoint<>(), 0, 0,
|
|
|
|
0, llvm::sys::fs::file_type::directory_file,
|
2015-10-13 00:16:39 +08:00
|
|
|
llvm::sys::fs::perms::all_all))),
|
|
|
|
UseNormalizedPaths(UseNormalizedPaths) {}
|
2015-10-05 21:55:14 +08:00
|
|
|
|
2018-03-29 06:09:09 +08:00
|
|
|
InMemoryFileSystem::~InMemoryFileSystem() = default;
|
2015-10-05 21:55:14 +08:00
|
|
|
|
2015-10-09 21:03:22 +08:00
|
|
|
std::string InMemoryFileSystem::toString() const {
|
2015-10-05 21:55:14 +08:00
|
|
|
return Root->toString(/*Indent=*/0);
|
|
|
|
}
|
|
|
|
|
2015-10-13 00:16:39 +08:00
|
|
|
bool InMemoryFileSystem::addFile(const Twine &P, time_t ModificationTime,
|
2017-11-10 00:01:16 +08:00
|
|
|
std::unique_ptr<llvm::MemoryBuffer> Buffer,
|
|
|
|
Optional<uint32_t> User,
|
|
|
|
Optional<uint32_t> Group,
|
|
|
|
Optional<llvm::sys::fs::file_type> Type,
|
2018-09-04 22:15:53 +08:00
|
|
|
Optional<llvm::sys::fs::perms> Perms,
|
|
|
|
const detail::InMemoryFile *HardLinkTarget) {
|
2015-10-05 21:55:14 +08:00
|
|
|
SmallString<128> Path;
|
|
|
|
P.toVector(Path);
|
|
|
|
|
|
|
|
// Fix up relative paths. This just prepends the current working directory.
|
2015-10-05 21:55:20 +08:00
|
|
|
std::error_code EC = makeAbsolute(Path);
|
2015-10-05 21:55:14 +08:00
|
|
|
assert(!EC);
|
|
|
|
(void)EC;
|
|
|
|
|
2015-10-13 00:16:39 +08:00
|
|
|
if (useNormalizedPaths())
|
2015-11-10 03:12:18 +08:00
|
|
|
llvm::sys::path::remove_dots(Path, /*remove_dot_dot=*/true);
|
2015-10-12 21:30:38 +08:00
|
|
|
|
2015-10-13 00:16:39 +08:00
|
|
|
if (Path.empty())
|
|
|
|
return false;
|
2015-10-12 21:30:38 +08:00
|
|
|
|
2015-10-13 00:16:39 +08:00
|
|
|
detail::InMemoryDirectory *Dir = Root.get();
|
2017-11-10 00:01:16 +08:00
|
|
|
auto I = llvm::sys::path::begin(Path), E = sys::path::end(Path);
|
|
|
|
const auto ResolvedUser = User.getValueOr(0);
|
|
|
|
const auto ResolvedGroup = Group.getValueOr(0);
|
|
|
|
const auto ResolvedType = Type.getValueOr(sys::fs::file_type::regular_file);
|
|
|
|
const auto ResolvedPerms = Perms.getValueOr(sys::fs::all_all);
|
2018-09-04 22:15:53 +08:00
|
|
|
assert(!(HardLinkTarget && Buffer) && "HardLink cannot have a buffer");
|
2017-11-10 00:01:16 +08:00
|
|
|
// Any intermediate directories we create should be accessible by
|
|
|
|
// the owner, even if Perms says otherwise for the final path.
|
|
|
|
const auto NewDirectoryPerms = ResolvedPerms | sys::fs::owner_all;
|
2015-10-05 21:55:14 +08:00
|
|
|
while (true) {
|
|
|
|
StringRef Name = *I;
|
|
|
|
detail::InMemoryNode *Node = Dir->getChild(Name);
|
|
|
|
++I;
|
|
|
|
if (!Node) {
|
|
|
|
if (I == E) {
|
2018-09-04 22:15:53 +08:00
|
|
|
// End of the path.
|
2017-11-17 03:34:08 +08:00
|
|
|
std::unique_ptr<detail::InMemoryNode> Child;
|
2018-09-04 22:15:53 +08:00
|
|
|
if (HardLinkTarget)
|
|
|
|
Child.reset(new detail::InMemoryHardLink(P.str(), *HardLinkTarget));
|
|
|
|
else {
|
|
|
|
// Create a new file or directory.
|
|
|
|
Status Stat(P.str(), getNextVirtualUniqueID(),
|
|
|
|
llvm::sys::toTimePoint(ModificationTime), ResolvedUser,
|
|
|
|
ResolvedGroup, Buffer->getBufferSize(), ResolvedType,
|
|
|
|
ResolvedPerms);
|
|
|
|
if (ResolvedType == sys::fs::file_type::directory_file) {
|
|
|
|
Child.reset(new detail::InMemoryDirectory(std::move(Stat)));
|
|
|
|
} else {
|
|
|
|
Child.reset(
|
|
|
|
new detail::InMemoryFile(std::move(Stat), std::move(Buffer)));
|
|
|
|
}
|
2017-11-17 03:34:08 +08:00
|
|
|
}
|
|
|
|
Dir->addChild(Name, std::move(Child));
|
2015-10-13 00:16:39 +08:00
|
|
|
return true;
|
2015-10-05 21:55:14 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
// Create a new directory. Use the path up to here.
|
|
|
|
Status Stat(
|
|
|
|
StringRef(Path.str().begin(), Name.end() - Path.str().begin()),
|
2017-11-10 00:01:16 +08:00
|
|
|
getNextVirtualUniqueID(), llvm::sys::toTimePoint(ModificationTime),
|
2018-09-04 22:15:53 +08:00
|
|
|
ResolvedUser, ResolvedGroup, 0, sys::fs::file_type::directory_file,
|
|
|
|
NewDirectoryPerms);
|
2015-10-05 21:55:14 +08:00
|
|
|
Dir = cast<detail::InMemoryDirectory>(Dir->addChild(
|
2019-08-15 23:54:37 +08:00
|
|
|
Name, std::make_unique<detail::InMemoryDirectory>(std::move(Stat))));
|
2015-10-05 21:55:14 +08:00
|
|
|
continue;
|
|
|
|
}
|
|
|
|
|
2015-10-13 00:16:39 +08:00
|
|
|
if (auto *NewDir = dyn_cast<detail::InMemoryDirectory>(Node)) {
|
2015-10-05 21:55:14 +08:00
|
|
|
Dir = NewDir;
|
2015-10-13 00:16:39 +08:00
|
|
|
} else {
|
2018-09-04 22:15:53 +08:00
|
|
|
assert((isa<detail::InMemoryFile>(Node) ||
|
|
|
|
isa<detail::InMemoryHardLink>(Node)) &&
|
|
|
|
"Must be either file, hardlink or directory!");
|
2015-10-13 00:16:39 +08:00
|
|
|
|
|
|
|
// Trying to insert a directory in place of a file.
|
|
|
|
if (I != E)
|
|
|
|
return false;
|
|
|
|
|
|
|
|
// Return false only if the new file is different from the existing one.
|
2018-09-04 22:15:53 +08:00
|
|
|
if (auto Link = dyn_cast<detail::InMemoryHardLink>(Node)) {
|
|
|
|
return Link->getResolvedFile().getBuffer()->getBuffer() ==
|
|
|
|
Buffer->getBuffer();
|
|
|
|
}
|
2015-10-13 00:16:39 +08:00
|
|
|
return cast<detail::InMemoryFile>(Node)->getBuffer()->getBuffer() ==
|
|
|
|
Buffer->getBuffer();
|
|
|
|
}
|
2015-10-05 21:55:14 +08:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2018-09-04 22:15:53 +08:00
|
|
|
bool InMemoryFileSystem::addFile(const Twine &P, time_t ModificationTime,
|
|
|
|
std::unique_ptr<llvm::MemoryBuffer> Buffer,
|
|
|
|
Optional<uint32_t> User,
|
|
|
|
Optional<uint32_t> Group,
|
|
|
|
Optional<llvm::sys::fs::file_type> Type,
|
|
|
|
Optional<llvm::sys::fs::perms> Perms) {
|
|
|
|
return addFile(P, ModificationTime, std::move(Buffer), User, Group, Type,
|
|
|
|
Perms, /*HardLinkTarget=*/nullptr);
|
|
|
|
}
|
|
|
|
|
2015-10-13 00:16:39 +08:00
|
|
|
bool InMemoryFileSystem::addFileNoOwn(const Twine &P, time_t ModificationTime,
|
2017-11-10 00:01:16 +08:00
|
|
|
llvm::MemoryBuffer *Buffer,
|
|
|
|
Optional<uint32_t> User,
|
|
|
|
Optional<uint32_t> Group,
|
|
|
|
Optional<llvm::sys::fs::file_type> Type,
|
|
|
|
Optional<llvm::sys::fs::perms> Perms) {
|
2015-10-06 18:04:08 +08:00
|
|
|
return addFile(P, ModificationTime,
|
|
|
|
llvm::MemoryBuffer::getMemBuffer(
|
2017-11-10 00:01:16 +08:00
|
|
|
Buffer->getBuffer(), Buffer->getBufferIdentifier()),
|
|
|
|
std::move(User), std::move(Group), std::move(Type),
|
|
|
|
std::move(Perms));
|
2015-10-06 18:04:08 +08:00
|
|
|
}
|
|
|
|
|
2018-09-04 22:15:53 +08:00
|
|
|
static ErrorOr<const detail::InMemoryNode *>
|
2015-10-05 21:55:20 +08:00
|
|
|
lookupInMemoryNode(const InMemoryFileSystem &FS, detail::InMemoryDirectory *Dir,
|
|
|
|
const Twine &P) {
|
2015-10-05 21:55:14 +08:00
|
|
|
SmallString<128> Path;
|
|
|
|
P.toVector(Path);
|
|
|
|
|
|
|
|
// Fix up relative paths. This just prepends the current working directory.
|
2015-10-05 21:55:20 +08:00
|
|
|
std::error_code EC = FS.makeAbsolute(Path);
|
2015-10-05 21:55:14 +08:00
|
|
|
assert(!EC);
|
|
|
|
(void)EC;
|
|
|
|
|
2015-10-13 00:16:39 +08:00
|
|
|
if (FS.useNormalizedPaths())
|
2015-11-10 03:12:18 +08:00
|
|
|
llvm::sys::path::remove_dots(Path, /*remove_dot_dot=*/true);
|
2015-10-12 21:30:38 +08:00
|
|
|
|
2015-10-13 00:16:39 +08:00
|
|
|
if (Path.empty())
|
2015-10-09 21:03:22 +08:00
|
|
|
return Dir;
|
|
|
|
|
2015-10-13 00:16:39 +08:00
|
|
|
auto I = llvm::sys::path::begin(Path), E = llvm::sys::path::end(Path);
|
2015-10-05 21:55:14 +08:00
|
|
|
while (true) {
|
|
|
|
detail::InMemoryNode *Node = Dir->getChild(*I);
|
|
|
|
++I;
|
|
|
|
if (!Node)
|
|
|
|
return errc::no_such_file_or_directory;
|
|
|
|
|
|
|
|
// Return the file if it's at the end of the path.
|
|
|
|
if (auto File = dyn_cast<detail::InMemoryFile>(Node)) {
|
|
|
|
if (I == E)
|
|
|
|
return File;
|
|
|
|
return errc::no_such_file_or_directory;
|
|
|
|
}
|
|
|
|
|
2018-09-04 22:15:53 +08:00
|
|
|
// If Node is HardLink then return the resolved file.
|
|
|
|
if (auto File = dyn_cast<detail::InMemoryHardLink>(Node)) {
|
|
|
|
if (I == E)
|
|
|
|
return &File->getResolvedFile();
|
|
|
|
return errc::no_such_file_or_directory;
|
|
|
|
}
|
2015-10-05 21:55:14 +08:00
|
|
|
// Traverse directories.
|
|
|
|
Dir = cast<detail::InMemoryDirectory>(Node);
|
|
|
|
if (I == E)
|
|
|
|
return Dir;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2018-09-04 22:15:53 +08:00
|
|
|
bool InMemoryFileSystem::addHardLink(const Twine &FromPath,
|
|
|
|
const Twine &ToPath) {
|
|
|
|
auto FromNode = lookupInMemoryNode(*this, Root.get(), FromPath);
|
|
|
|
auto ToNode = lookupInMemoryNode(*this, Root.get(), ToPath);
|
|
|
|
// FromPath must not have been added before. ToPath must have been added
|
|
|
|
// before. Resolved ToPath must be a File.
|
|
|
|
if (!ToNode || FromNode || !isa<detail::InMemoryFile>(*ToNode))
|
|
|
|
return false;
|
|
|
|
return this->addFile(FromPath, 0, nullptr, None, None, None, None,
|
|
|
|
cast<detail::InMemoryFile>(*ToNode));
|
|
|
|
}
|
|
|
|
|
2015-10-05 21:55:14 +08:00
|
|
|
llvm::ErrorOr<Status> InMemoryFileSystem::status(const Twine &Path) {
|
2015-10-05 21:55:20 +08:00
|
|
|
auto Node = lookupInMemoryNode(*this, Root.get(), Path);
|
2015-10-05 21:55:14 +08:00
|
|
|
if (Node)
|
2019-02-24 07:48:47 +08:00
|
|
|
return detail::getNodeStatus(*Node, Path);
|
2015-10-05 21:55:14 +08:00
|
|
|
return Node.getError();
|
|
|
|
}
|
|
|
|
|
|
|
|
llvm::ErrorOr<std::unique_ptr<File>>
|
|
|
|
InMemoryFileSystem::openFileForRead(const Twine &Path) {
|
2015-10-05 21:55:20 +08:00
|
|
|
auto Node = lookupInMemoryNode(*this, Root.get(), Path);
|
2015-10-05 21:55:14 +08:00
|
|
|
if (!Node)
|
|
|
|
return Node.getError();
|
|
|
|
|
|
|
|
// When we have a file provide a heap-allocated wrapper for the memory buffer
|
|
|
|
// to match the ownership semantics for File.
|
|
|
|
if (auto *F = dyn_cast<detail::InMemoryFile>(*Node))
|
[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
|
|
|
return std::unique_ptr<File>(
|
|
|
|
new detail::InMemoryFileAdaptor(*F, Path.str()));
|
2015-10-05 21:55:14 +08:00
|
|
|
|
|
|
|
// FIXME: errc::not_a_file?
|
|
|
|
return make_error_code(llvm::errc::invalid_argument);
|
|
|
|
}
|
|
|
|
|
|
|
|
namespace {
|
2018-03-29 06:09:09 +08:00
|
|
|
|
2015-10-05 21:55:14 +08:00
|
|
|
/// Adaptor from InMemoryDir::iterator to directory_iterator.
|
2018-10-10 21:27:25 +08:00
|
|
|
class InMemoryDirIterator : public llvm::vfs::detail::DirIterImpl {
|
2015-10-05 21:55:14 +08:00
|
|
|
detail::InMemoryDirectory::const_iterator I;
|
|
|
|
detail::InMemoryDirectory::const_iterator E;
|
[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
|
|
|
std::string RequestedDirName;
|
|
|
|
|
|
|
|
void setCurrentEntry() {
|
|
|
|
if (I != E) {
|
|
|
|
SmallString<256> Path(RequestedDirName);
|
|
|
|
llvm::sys::path::append(Path, I->second->getFileName());
|
2019-11-05 01:23:07 +08:00
|
|
|
sys::fs::file_type Type = sys::fs::file_type::type_unknown;
|
2018-09-14 20:47:38 +08:00
|
|
|
switch (I->second->getKind()) {
|
2018-10-10 21:27:25 +08:00
|
|
|
case detail::IME_File:
|
|
|
|
case detail::IME_HardLink:
|
|
|
|
Type = sys::fs::file_type::regular_file;
|
|
|
|
break;
|
|
|
|
case detail::IME_Directory:
|
|
|
|
Type = sys::fs::file_type::directory_file;
|
|
|
|
break;
|
2018-09-14 20:47:38 +08:00
|
|
|
}
|
2020-01-29 03:23:46 +08:00
|
|
|
CurrentEntry = directory_entry(std::string(Path.str()), Type);
|
[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
|
|
|
} else {
|
|
|
|
// When we're at the end, make CurrentEntry invalid and DirIterImpl will
|
|
|
|
// do the rest.
|
2018-09-14 20:47:38 +08:00
|
|
|
CurrentEntry = directory_entry();
|
[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
|
|
|
}
|
|
|
|
}
|
2015-10-05 21:55:14 +08:00
|
|
|
|
|
|
|
public:
|
2018-03-29 06:09:09 +08:00
|
|
|
InMemoryDirIterator() = default;
|
|
|
|
|
2018-09-04 22:15:53 +08:00
|
|
|
explicit InMemoryDirIterator(const detail::InMemoryDirectory &Dir,
|
[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
|
|
|
std::string RequestedDirName)
|
|
|
|
: I(Dir.begin()), E(Dir.end()),
|
|
|
|
RequestedDirName(std::move(RequestedDirName)) {
|
|
|
|
setCurrentEntry();
|
2015-10-05 21:55:14 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
std::error_code increment() override {
|
|
|
|
++I;
|
[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
|
|
|
setCurrentEntry();
|
2018-03-29 06:09:09 +08:00
|
|
|
return {};
|
2015-10-05 21:55:14 +08:00
|
|
|
}
|
|
|
|
};
|
2018-03-29 06:09:09 +08:00
|
|
|
|
|
|
|
} // namespace
|
2015-10-05 21:55:14 +08:00
|
|
|
|
|
|
|
directory_iterator InMemoryFileSystem::dir_begin(const Twine &Dir,
|
|
|
|
std::error_code &EC) {
|
2015-10-05 21:55:20 +08:00
|
|
|
auto Node = lookupInMemoryNode(*this, Root.get(), Dir);
|
2015-10-05 21:55:14 +08:00
|
|
|
if (!Node) {
|
|
|
|
EC = Node.getError();
|
|
|
|
return directory_iterator(std::make_shared<InMemoryDirIterator>());
|
|
|
|
}
|
|
|
|
|
|
|
|
if (auto *DirNode = dyn_cast<detail::InMemoryDirectory>(*Node))
|
[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
|
|
|
return directory_iterator(
|
|
|
|
std::make_shared<InMemoryDirIterator>(*DirNode, Dir.str()));
|
2015-10-05 21:55:14 +08:00
|
|
|
|
|
|
|
EC = make_error_code(llvm::errc::not_a_directory);
|
|
|
|
return directory_iterator(std::make_shared<InMemoryDirIterator>());
|
|
|
|
}
|
2016-01-10 00:33:16 +08:00
|
|
|
|
|
|
|
std::error_code InMemoryFileSystem::setCurrentWorkingDirectory(const Twine &P) {
|
|
|
|
SmallString<128> Path;
|
|
|
|
P.toVector(Path);
|
|
|
|
|
|
|
|
// Fix up relative paths. This just prepends the current working directory.
|
|
|
|
std::error_code EC = makeAbsolute(Path);
|
|
|
|
assert(!EC);
|
|
|
|
(void)EC;
|
|
|
|
|
|
|
|
if (useNormalizedPaths())
|
|
|
|
llvm::sys::path::remove_dots(Path, /*remove_dot_dot=*/true);
|
|
|
|
|
|
|
|
if (!Path.empty())
|
2020-01-29 03:23:46 +08:00
|
|
|
WorkingDirectory = std::string(Path.str());
|
2018-03-29 06:09:09 +08:00
|
|
|
return {};
|
2015-10-05 21:55:14 +08:00
|
|
|
}
|
|
|
|
|
2018-11-09 23:11:34 +08:00
|
|
|
std::error_code
|
|
|
|
InMemoryFileSystem::getRealPath(const Twine &Path,
|
|
|
|
SmallVectorImpl<char> &Output) const {
|
2018-05-24 19:17:00 +08:00
|
|
|
auto CWD = getCurrentWorkingDirectory();
|
|
|
|
if (!CWD || CWD->empty())
|
|
|
|
return errc::operation_not_permitted;
|
|
|
|
Path.toVector(Output);
|
|
|
|
if (auto EC = makeAbsolute(Output))
|
|
|
|
return EC;
|
|
|
|
llvm::sys::path::remove_dots(Output, /*remove_dot_dot=*/true);
|
|
|
|
return {};
|
|
|
|
}
|
|
|
|
|
2018-11-08 08:01:32 +08:00
|
|
|
std::error_code InMemoryFileSystem::isLocal(const Twine &Path, bool &Result) {
|
|
|
|
Result = false;
|
|
|
|
return {};
|
|
|
|
}
|
|
|
|
|
2018-03-29 06:09:09 +08:00
|
|
|
} // namespace vfs
|
2018-10-10 21:27:25 +08:00
|
|
|
} // namespace llvm
|
2018-03-29 06:09:09 +08:00
|
|
|
|
2014-02-22 07:39:37 +08:00
|
|
|
//===-----------------------------------------------------------------------===/
|
2015-10-07 18:05:44 +08:00
|
|
|
// RedirectingFileSystem implementation
|
2014-02-22 07:39:37 +08:00
|
|
|
//===-----------------------------------------------------------------------===/
|
|
|
|
|
2020-01-22 08:45:51 +08:00
|
|
|
namespace {
|
|
|
|
|
|
|
|
/// Removes leading "./" as well as path components like ".." and ".".
|
|
|
|
static llvm::SmallString<256> canonicalize(llvm::StringRef Path) {
|
|
|
|
// First detect the path style in use by checking the first separator.
|
|
|
|
llvm::sys::path::Style style = llvm::sys::path::Style::native;
|
|
|
|
const size_t n = Path.find_first_of("/\\");
|
|
|
|
if (n != static_cast<size_t>(-1))
|
|
|
|
style = (Path[n] == '/') ? llvm::sys::path::Style::posix
|
|
|
|
: llvm::sys::path::Style::windows;
|
|
|
|
|
|
|
|
// Now remove the dots. Explicitly specifying the path style prevents the
|
|
|
|
// direction of the slashes from changing.
|
|
|
|
llvm::SmallString<256> result =
|
|
|
|
llvm::sys::path::remove_leading_dotslash(Path, style);
|
|
|
|
llvm::sys::path::remove_dots(result, /*remove_dot_dot=*/true, style);
|
|
|
|
return result;
|
|
|
|
}
|
|
|
|
|
|
|
|
} // anonymous namespace
|
|
|
|
|
|
|
|
|
2019-10-16 07:08:57 +08:00
|
|
|
RedirectingFileSystem::RedirectingFileSystem(IntrusiveRefCntPtr<FileSystem> FS)
|
|
|
|
: ExternalFS(std::move(FS)) {
|
|
|
|
if (ExternalFS)
|
|
|
|
if (auto ExternalWorkingDirectory =
|
|
|
|
ExternalFS->getCurrentWorkingDirectory()) {
|
|
|
|
WorkingDirectory = *ExternalWorkingDirectory;
|
|
|
|
ExternalFSValidWD = true;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2018-10-27 06:14:33 +08:00
|
|
|
// FIXME: reuse implementation common with OverlayFSDirIterImpl as these
|
|
|
|
// iterators are conceptually similar.
|
2019-01-16 06:36:41 +08:00
|
|
|
class llvm::vfs::VFSFromYamlDirIterImpl
|
|
|
|
: public llvm::vfs::detail::DirIterImpl {
|
2014-06-25 03:37:16 +08:00
|
|
|
std::string Dir;
|
2019-01-16 06:36:41 +08:00
|
|
|
RedirectingFileSystem::RedirectingDirectoryEntry::iterator Current, End;
|
2015-10-09 21:28:13 +08:00
|
|
|
|
2018-10-27 06:14:33 +08:00
|
|
|
// To handle 'fallthrough' mode we need to iterate at first through
|
|
|
|
// RedirectingDirectoryEntry and then through ExternalFS. These operations are
|
|
|
|
// done sequentially, we just need to keep a track of what kind of iteration
|
|
|
|
// we are currently performing.
|
|
|
|
|
|
|
|
/// Flag telling if we should iterate through ExternalFS or stop at the last
|
|
|
|
/// RedirectingDirectoryEntry::iterator.
|
|
|
|
bool IterateExternalFS;
|
|
|
|
/// Flag telling if we have switched to iterating through ExternalFS.
|
|
|
|
bool IsExternalFSCurrent = false;
|
|
|
|
FileSystem &ExternalFS;
|
|
|
|
directory_iterator ExternalDirIter;
|
|
|
|
llvm::StringSet<> SeenNames;
|
|
|
|
|
|
|
|
/// To combine multiple iterations, different methods are responsible for
|
|
|
|
/// different iteration steps.
|
|
|
|
/// @{
|
|
|
|
|
|
|
|
/// Responsible for dispatching between RedirectingDirectoryEntry iteration
|
|
|
|
/// and ExternalFS iteration.
|
|
|
|
std::error_code incrementImpl(bool IsFirstTime);
|
|
|
|
/// Responsible for RedirectingDirectoryEntry iteration.
|
|
|
|
std::error_code incrementContent(bool IsFirstTime);
|
|
|
|
/// Responsible for ExternalFS iteration.
|
|
|
|
std::error_code incrementExternal();
|
|
|
|
/// @}
|
2018-08-08 07:00:40 +08:00
|
|
|
|
2014-06-25 03:37:16 +08:00
|
|
|
public:
|
2019-01-16 06:36:41 +08:00
|
|
|
VFSFromYamlDirIterImpl(
|
|
|
|
const Twine &Path,
|
|
|
|
RedirectingFileSystem::RedirectingDirectoryEntry::iterator Begin,
|
|
|
|
RedirectingFileSystem::RedirectingDirectoryEntry::iterator End,
|
|
|
|
bool IterateExternalFS, FileSystem &ExternalFS, std::error_code &EC);
|
2018-03-29 06:09:09 +08:00
|
|
|
|
2014-06-25 03:37:16 +08:00
|
|
|
std::error_code increment() override;
|
|
|
|
};
|
|
|
|
|
2019-01-16 06:36:41 +08:00
|
|
|
llvm::ErrorOr<std::string>
|
|
|
|
RedirectingFileSystem::getCurrentWorkingDirectory() const {
|
2019-10-16 07:08:57 +08:00
|
|
|
return WorkingDirectory;
|
2019-01-16 06:36:41 +08:00
|
|
|
}
|
2014-02-22 07:39:37 +08:00
|
|
|
|
2019-01-16 06:36:41 +08:00
|
|
|
std::error_code
|
|
|
|
RedirectingFileSystem::setCurrentWorkingDirectory(const Twine &Path) {
|
2019-10-16 07:08:57 +08:00
|
|
|
// Don't change the working directory if the path doesn't exist.
|
|
|
|
if (!exists(Path))
|
|
|
|
return errc::no_such_file_or_directory;
|
|
|
|
|
|
|
|
// Always change the external FS but ignore its result.
|
|
|
|
if (ExternalFS) {
|
|
|
|
auto EC = ExternalFS->setCurrentWorkingDirectory(Path);
|
|
|
|
ExternalFSValidWD = !static_cast<bool>(EC);
|
|
|
|
}
|
|
|
|
|
|
|
|
SmallString<128> AbsolutePath;
|
|
|
|
Path.toVector(AbsolutePath);
|
|
|
|
if (std::error_code EC = makeAbsolute(AbsolutePath))
|
|
|
|
return EC;
|
2020-01-29 03:23:46 +08:00
|
|
|
WorkingDirectory = std::string(AbsolutePath.str());
|
2019-10-16 07:08:57 +08:00
|
|
|
return {};
|
2019-01-16 06:36:41 +08:00
|
|
|
}
|
2014-06-25 03:37:16 +08:00
|
|
|
|
2019-01-16 06:36:41 +08:00
|
|
|
std::error_code RedirectingFileSystem::isLocal(const Twine &Path,
|
|
|
|
bool &Result) {
|
|
|
|
return ExternalFS->isLocal(Path, Result);
|
|
|
|
}
|
2018-11-16 09:15:54 +08:00
|
|
|
|
2019-11-26 07:57:21 +08:00
|
|
|
std::error_code RedirectingFileSystem::makeAbsolute(SmallVectorImpl<char> &Path) const {
|
|
|
|
if (llvm::sys::path::is_absolute(Path, llvm::sys::path::Style::posix) ||
|
|
|
|
llvm::sys::path::is_absolute(Path, llvm::sys::path::Style::windows))
|
|
|
|
return {};
|
|
|
|
|
|
|
|
auto WorkingDir = getCurrentWorkingDirectory();
|
|
|
|
if (!WorkingDir)
|
|
|
|
return WorkingDir.getError();
|
|
|
|
|
2020-01-22 08:45:51 +08:00
|
|
|
// We can't use sys::fs::make_absolute because that assumes the path style
|
|
|
|
// is native and there is no way to override that. Since we know WorkingDir
|
|
|
|
// is absolute, we can use it to determine which style we actually have and
|
|
|
|
// append Path ourselves.
|
|
|
|
sys::path::Style style = sys::path::Style::windows;
|
|
|
|
if (sys::path::is_absolute(WorkingDir.get(), sys::path::Style::posix)) {
|
|
|
|
style = sys::path::Style::posix;
|
|
|
|
}
|
|
|
|
|
|
|
|
std::string Result = WorkingDir.get();
|
|
|
|
StringRef Dir(Result);
|
|
|
|
if (!Dir.endswith(sys::path::get_separator(style))) {
|
|
|
|
Result += sys::path::get_separator(style);
|
|
|
|
}
|
|
|
|
Result.append(Path.data(), Path.size());
|
|
|
|
Path.assign(Result.begin(), Result.end());
|
|
|
|
|
2019-11-26 07:57:21 +08:00
|
|
|
return {};
|
|
|
|
}
|
|
|
|
|
2019-01-16 06:36:41 +08:00
|
|
|
directory_iterator RedirectingFileSystem::dir_begin(const Twine &Dir,
|
|
|
|
std::error_code &EC) {
|
|
|
|
ErrorOr<RedirectingFileSystem::Entry *> E = lookupPath(Dir);
|
|
|
|
if (!E) {
|
|
|
|
EC = E.getError();
|
2019-10-16 07:08:57 +08:00
|
|
|
if (shouldUseExternalFS() && EC == errc::no_such_file_or_directory)
|
2019-01-16 06:36:41 +08:00
|
|
|
return ExternalFS->dir_begin(Dir, EC);
|
|
|
|
return {};
|
2015-10-05 21:55:20 +08:00
|
|
|
}
|
2019-01-16 06:36:41 +08:00
|
|
|
ErrorOr<Status> S = status(Dir, *E);
|
|
|
|
if (!S) {
|
|
|
|
EC = S.getError();
|
|
|
|
return {};
|
2015-10-05 21:55:20 +08:00
|
|
|
}
|
2019-01-16 06:36:41 +08:00
|
|
|
if (!S->isDirectory()) {
|
|
|
|
EC = std::error_code(static_cast<int>(errc::not_a_directory),
|
|
|
|
std::system_category());
|
|
|
|
return {};
|
2018-11-08 08:01:32 +08:00
|
|
|
}
|
|
|
|
|
2019-01-16 06:36:41 +08:00
|
|
|
auto *D = cast<RedirectingFileSystem::RedirectingDirectoryEntry>(*E);
|
|
|
|
return directory_iterator(std::make_shared<VFSFromYamlDirIterImpl>(
|
|
|
|
Dir, D->contents_begin(), D->contents_end(),
|
2019-10-16 07:08:57 +08:00
|
|
|
/*IterateExternalFS=*/shouldUseExternalFS(), *ExternalFS, EC));
|
2019-01-16 06:36:41 +08:00
|
|
|
}
|
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
|
|
|
|
2019-01-16 06:36:41 +08:00
|
|
|
void RedirectingFileSystem::setExternalContentsPrefixDir(StringRef PrefixDir) {
|
|
|
|
ExternalContentsPrefixDir = PrefixDir.str();
|
|
|
|
}
|
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
|
|
|
|
2019-01-16 06:36:41 +08:00
|
|
|
StringRef RedirectingFileSystem::getExternalContentsPrefixDir() const {
|
|
|
|
return ExternalContentsPrefixDir;
|
|
|
|
}
|
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
|
|
|
|
2019-09-14 07:27:31 +08:00
|
|
|
void RedirectingFileSystem::dump(raw_ostream &OS) const {
|
2019-01-16 06:36:41 +08:00
|
|
|
for (const auto &Root : Roots)
|
2019-09-14 07:27:31 +08:00
|
|
|
dumpEntry(OS, Root.get());
|
2019-01-16 06:36:41 +08:00
|
|
|
}
|
2016-05-07 07:21:57 +08:00
|
|
|
|
2019-09-14 07:27:31 +08:00
|
|
|
void RedirectingFileSystem::dumpEntry(raw_ostream &OS,
|
|
|
|
RedirectingFileSystem::Entry *E,
|
|
|
|
int NumSpaces) const {
|
2019-01-16 06:36:41 +08:00
|
|
|
StringRef Name = E->getName();
|
|
|
|
for (int i = 0, e = NumSpaces; i < e; ++i)
|
2019-09-14 07:27:31 +08:00
|
|
|
OS << " ";
|
|
|
|
OS << "'" << Name.str().c_str() << "'"
|
|
|
|
<< "\n";
|
2016-05-07 07:21:57 +08:00
|
|
|
|
2019-01-16 06:36:41 +08:00
|
|
|
if (E->getKind() == RedirectingFileSystem::EK_Directory) {
|
|
|
|
auto *DE = dyn_cast<RedirectingFileSystem::RedirectingDirectoryEntry>(E);
|
|
|
|
assert(DE && "Should be a directory");
|
2016-05-07 07:21:57 +08:00
|
|
|
|
2019-01-16 06:36:41 +08:00
|
|
|
for (std::unique_ptr<Entry> &SubEntry :
|
|
|
|
llvm::make_range(DE->contents_begin(), DE->contents_end()))
|
2019-09-14 07:27:31 +08:00
|
|
|
dumpEntry(OS, SubEntry.get(), NumSpaces + 2);
|
2016-05-07 07:21:57 +08:00
|
|
|
}
|
2019-01-16 06:36:41 +08:00
|
|
|
}
|
2019-09-14 07:27:31 +08:00
|
|
|
|
|
|
|
#if !defined(NDEBUG) || defined(LLVM_ENABLE_DUMP)
|
|
|
|
LLVM_DUMP_METHOD void RedirectingFileSystem::dump() const { dump(dbgs()); }
|
2016-05-07 07:21:57 +08:00
|
|
|
#endif
|
2014-02-22 07:39:37 +08:00
|
|
|
|
2018-05-09 09:00:01 +08:00
|
|
|
/// A helper class to hold the common YAML parsing state.
|
2019-01-16 06:36:41 +08:00
|
|
|
class llvm::vfs::RedirectingFileSystemParser {
|
2014-02-22 07:39:37 +08:00
|
|
|
yaml::Stream &Stream;
|
|
|
|
|
2018-10-10 21:27:25 +08:00
|
|
|
void error(yaml::Node *N, const Twine &Msg) { Stream.printError(N, Msg); }
|
2014-02-22 07:39:37 +08:00
|
|
|
|
|
|
|
// false on error
|
|
|
|
bool parseScalarString(yaml::Node *N, StringRef &Result,
|
|
|
|
SmallVectorImpl<char> &Storage) {
|
2018-03-29 06:09:09 +08:00
|
|
|
const auto *S = dyn_cast<yaml::ScalarNode>(N);
|
|
|
|
|
2014-02-22 07:39:37 +08:00
|
|
|
if (!S) {
|
|
|
|
error(N, "expected string");
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
Result = S->getValue(Storage);
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
|
|
|
// false on error
|
|
|
|
bool parseScalarBool(yaml::Node *N, bool &Result) {
|
|
|
|
SmallString<5> Storage;
|
|
|
|
StringRef Value;
|
|
|
|
if (!parseScalarString(N, Value, Storage))
|
|
|
|
return false;
|
|
|
|
|
|
|
|
if (Value.equals_lower("true") || Value.equals_lower("on") ||
|
|
|
|
Value.equals_lower("yes") || Value == "1") {
|
|
|
|
Result = true;
|
|
|
|
return true;
|
|
|
|
} else if (Value.equals_lower("false") || Value.equals_lower("off") ||
|
|
|
|
Value.equals_lower("no") || Value == "0") {
|
|
|
|
Result = false;
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
|
|
|
error(N, "expected boolean value");
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
|
|
|
struct KeyStatus {
|
|
|
|
bool Required;
|
2018-03-29 06:09:09 +08:00
|
|
|
bool Seen = false;
|
|
|
|
|
|
|
|
KeyStatus(bool Required = false) : Required(Required) {}
|
2014-02-22 07:39:37 +08:00
|
|
|
};
|
2018-03-29 06:09:09 +08:00
|
|
|
|
|
|
|
using KeyStatusPair = std::pair<StringRef, KeyStatus>;
|
2014-02-22 07:39:37 +08:00
|
|
|
|
|
|
|
// false on error
|
|
|
|
bool checkDuplicateOrUnknownKey(yaml::Node *KeyNode, StringRef Key,
|
|
|
|
DenseMap<StringRef, KeyStatus> &Keys) {
|
|
|
|
if (!Keys.count(Key)) {
|
|
|
|
error(KeyNode, "unknown key");
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
KeyStatus &S = Keys[Key];
|
|
|
|
if (S.Seen) {
|
|
|
|
error(KeyNode, Twine("duplicate key '") + Key + "'");
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
S.Seen = true;
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
|
|
|
// false on error
|
|
|
|
bool checkMissingKeys(yaml::Node *Obj, DenseMap<StringRef, KeyStatus> &Keys) {
|
2018-03-29 06:09:09 +08:00
|
|
|
for (const auto &I : Keys) {
|
|
|
|
if (I.second.Required && !I.second.Seen) {
|
|
|
|
error(Obj, Twine("missing key '") + I.first + "'");
|
2014-02-22 07:39:37 +08:00
|
|
|
return false;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
2019-01-16 06:36:41 +08:00
|
|
|
RedirectingFileSystem::Entry *
|
|
|
|
lookupOrCreateEntry(RedirectingFileSystem *FS, StringRef Name,
|
|
|
|
RedirectingFileSystem::Entry *ParentEntry = nullptr) {
|
[VFS] Reapply #2: Reconstruct the VFS overlay tree for more accurate lookup
Reapply r269100 and r269270, reverted due to
https://llvm.org/bugs/show_bug.cgi?id=27725. Isolate the testcase that
corresponds to the new feature side of this commit and skip it on
windows hosts until we find why it does not work on these platforms.
Original commit message:
The way we currently build the internal VFS overlay representation leads
to inefficient path search and might yield wrong answers when asked for
recursive or regular directory iteration.
Currently, when reading an YAML file, each YAML root entry is placed
inside a new root in the filesystem overlay. In the crash reproducer, a
simple "@import Foundation" currently maps to 43 roots, and when looking
up paths, we traverse a directory tree for each of these different
roots, until we find a match (or don't). This has two consequences:
- It's slow.
- Directory iteration gives incomplete results since it only return
results within one root - since contents of the same directory can be
declared inside different roots, the result isn't accurate.
This is in part fault of the way we currently write out the YAML file
when emitting the crash reproducer - we could generate only one root and
that would make it fast and correct again. However, we should not rely
on how the client writes the YAML, but provide a good internal
representation regardless.
Build a proper virtual directory tree out of the YAML representation,
allowing faster search and proper iteration. Besides the crash
reproducer, this potentially benefits other VFS clients.
llvm-svn: 269327
2016-05-13 03:13:07 +08:00
|
|
|
if (!ParentEntry) { // Look for a existent root
|
2018-03-29 06:09:09 +08:00
|
|
|
for (const auto &Root : FS->Roots) {
|
[VFS] Reapply #2: Reconstruct the VFS overlay tree for more accurate lookup
Reapply r269100 and r269270, reverted due to
https://llvm.org/bugs/show_bug.cgi?id=27725. Isolate the testcase that
corresponds to the new feature side of this commit and skip it on
windows hosts until we find why it does not work on these platforms.
Original commit message:
The way we currently build the internal VFS overlay representation leads
to inefficient path search and might yield wrong answers when asked for
recursive or regular directory iteration.
Currently, when reading an YAML file, each YAML root entry is placed
inside a new root in the filesystem overlay. In the crash reproducer, a
simple "@import Foundation" currently maps to 43 roots, and when looking
up paths, we traverse a directory tree for each of these different
roots, until we find a match (or don't). This has two consequences:
- It's slow.
- Directory iteration gives incomplete results since it only return
results within one root - since contents of the same directory can be
declared inside different roots, the result isn't accurate.
This is in part fault of the way we currently write out the YAML file
when emitting the crash reproducer - we could generate only one root and
that would make it fast and correct again. However, we should not rely
on how the client writes the YAML, but provide a good internal
representation regardless.
Build a proper virtual directory tree out of the YAML representation,
allowing faster search and proper iteration. Besides the crash
reproducer, this potentially benefits other VFS clients.
llvm-svn: 269327
2016-05-13 03:13:07 +08:00
|
|
|
if (Name.equals(Root->getName())) {
|
|
|
|
ParentEntry = Root.get();
|
|
|
|
return ParentEntry;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
} else { // Advance to the next component
|
2019-01-16 06:36:41 +08:00
|
|
|
auto *DE = dyn_cast<RedirectingFileSystem::RedirectingDirectoryEntry>(
|
|
|
|
ParentEntry);
|
|
|
|
for (std::unique_ptr<RedirectingFileSystem::Entry> &Content :
|
[VFS] Reapply #2: Reconstruct the VFS overlay tree for more accurate lookup
Reapply r269100 and r269270, reverted due to
https://llvm.org/bugs/show_bug.cgi?id=27725. Isolate the testcase that
corresponds to the new feature side of this commit and skip it on
windows hosts until we find why it does not work on these platforms.
Original commit message:
The way we currently build the internal VFS overlay representation leads
to inefficient path search and might yield wrong answers when asked for
recursive or regular directory iteration.
Currently, when reading an YAML file, each YAML root entry is placed
inside a new root in the filesystem overlay. In the crash reproducer, a
simple "@import Foundation" currently maps to 43 roots, and when looking
up paths, we traverse a directory tree for each of these different
roots, until we find a match (or don't). This has two consequences:
- It's slow.
- Directory iteration gives incomplete results since it only return
results within one root - since contents of the same directory can be
declared inside different roots, the result isn't accurate.
This is in part fault of the way we currently write out the YAML file
when emitting the crash reproducer - we could generate only one root and
that would make it fast and correct again. However, we should not rely
on how the client writes the YAML, but provide a good internal
representation regardless.
Build a proper virtual directory tree out of the YAML representation,
allowing faster search and proper iteration. Besides the crash
reproducer, this potentially benefits other VFS clients.
llvm-svn: 269327
2016-05-13 03:13:07 +08:00
|
|
|
llvm::make_range(DE->contents_begin(), DE->contents_end())) {
|
2019-01-16 06:36:41 +08:00
|
|
|
auto *DirContent =
|
|
|
|
dyn_cast<RedirectingFileSystem::RedirectingDirectoryEntry>(
|
|
|
|
Content.get());
|
[VFS] Reapply #2: Reconstruct the VFS overlay tree for more accurate lookup
Reapply r269100 and r269270, reverted due to
https://llvm.org/bugs/show_bug.cgi?id=27725. Isolate the testcase that
corresponds to the new feature side of this commit and skip it on
windows hosts until we find why it does not work on these platforms.
Original commit message:
The way we currently build the internal VFS overlay representation leads
to inefficient path search and might yield wrong answers when asked for
recursive or regular directory iteration.
Currently, when reading an YAML file, each YAML root entry is placed
inside a new root in the filesystem overlay. In the crash reproducer, a
simple "@import Foundation" currently maps to 43 roots, and when looking
up paths, we traverse a directory tree for each of these different
roots, until we find a match (or don't). This has two consequences:
- It's slow.
- Directory iteration gives incomplete results since it only return
results within one root - since contents of the same directory can be
declared inside different roots, the result isn't accurate.
This is in part fault of the way we currently write out the YAML file
when emitting the crash reproducer - we could generate only one root and
that would make it fast and correct again. However, we should not rely
on how the client writes the YAML, but provide a good internal
representation regardless.
Build a proper virtual directory tree out of the YAML representation,
allowing faster search and proper iteration. Besides the crash
reproducer, this potentially benefits other VFS clients.
llvm-svn: 269327
2016-05-13 03:13:07 +08:00
|
|
|
if (DirContent && Name.equals(Content->getName()))
|
|
|
|
return DirContent;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
// ... or create a new one
|
2019-01-16 06:36:41 +08:00
|
|
|
std::unique_ptr<RedirectingFileSystem::Entry> E =
|
2019-08-15 23:54:37 +08:00
|
|
|
std::make_unique<RedirectingFileSystem::RedirectingDirectoryEntry>(
|
2019-01-16 06:36:41 +08:00
|
|
|
Name, Status("", getNextVirtualUniqueID(),
|
|
|
|
std::chrono::system_clock::now(), 0, 0, 0,
|
|
|
|
file_type::directory_file, sys::fs::all_all));
|
[VFS] Reapply #2: Reconstruct the VFS overlay tree for more accurate lookup
Reapply r269100 and r269270, reverted due to
https://llvm.org/bugs/show_bug.cgi?id=27725. Isolate the testcase that
corresponds to the new feature side of this commit and skip it on
windows hosts until we find why it does not work on these platforms.
Original commit message:
The way we currently build the internal VFS overlay representation leads
to inefficient path search and might yield wrong answers when asked for
recursive or regular directory iteration.
Currently, when reading an YAML file, each YAML root entry is placed
inside a new root in the filesystem overlay. In the crash reproducer, a
simple "@import Foundation" currently maps to 43 roots, and when looking
up paths, we traverse a directory tree for each of these different
roots, until we find a match (or don't). This has two consequences:
- It's slow.
- Directory iteration gives incomplete results since it only return
results within one root - since contents of the same directory can be
declared inside different roots, the result isn't accurate.
This is in part fault of the way we currently write out the YAML file
when emitting the crash reproducer - we could generate only one root and
that would make it fast and correct again. However, we should not rely
on how the client writes the YAML, but provide a good internal
representation regardless.
Build a proper virtual directory tree out of the YAML representation,
allowing faster search and proper iteration. Besides the crash
reproducer, this potentially benefits other VFS clients.
llvm-svn: 269327
2016-05-13 03:13:07 +08:00
|
|
|
|
|
|
|
if (!ParentEntry) { // Add a new root to the overlay
|
|
|
|
FS->Roots.push_back(std::move(E));
|
|
|
|
ParentEntry = FS->Roots.back().get();
|
|
|
|
return ParentEntry;
|
|
|
|
}
|
|
|
|
|
2019-01-16 06:36:41 +08:00
|
|
|
auto *DE =
|
2019-10-01 19:25:29 +08:00
|
|
|
cast<RedirectingFileSystem::RedirectingDirectoryEntry>(ParentEntry);
|
[VFS] Reapply #2: Reconstruct the VFS overlay tree for more accurate lookup
Reapply r269100 and r269270, reverted due to
https://llvm.org/bugs/show_bug.cgi?id=27725. Isolate the testcase that
corresponds to the new feature side of this commit and skip it on
windows hosts until we find why it does not work on these platforms.
Original commit message:
The way we currently build the internal VFS overlay representation leads
to inefficient path search and might yield wrong answers when asked for
recursive or regular directory iteration.
Currently, when reading an YAML file, each YAML root entry is placed
inside a new root in the filesystem overlay. In the crash reproducer, a
simple "@import Foundation" currently maps to 43 roots, and when looking
up paths, we traverse a directory tree for each of these different
roots, until we find a match (or don't). This has two consequences:
- It's slow.
- Directory iteration gives incomplete results since it only return
results within one root - since contents of the same directory can be
declared inside different roots, the result isn't accurate.
This is in part fault of the way we currently write out the YAML file
when emitting the crash reproducer - we could generate only one root and
that would make it fast and correct again. However, we should not rely
on how the client writes the YAML, but provide a good internal
representation regardless.
Build a proper virtual directory tree out of the YAML representation,
allowing faster search and proper iteration. Besides the crash
reproducer, this potentially benefits other VFS clients.
llvm-svn: 269327
2016-05-13 03:13:07 +08:00
|
|
|
DE->addContent(std::move(E));
|
|
|
|
return DE->getLastContent();
|
|
|
|
}
|
|
|
|
|
2019-01-16 06:36:41 +08:00
|
|
|
void uniqueOverlayTree(RedirectingFileSystem *FS,
|
|
|
|
RedirectingFileSystem::Entry *SrcE,
|
|
|
|
RedirectingFileSystem::Entry *NewParentE = nullptr) {
|
[VFS] Reapply #2: Reconstruct the VFS overlay tree for more accurate lookup
Reapply r269100 and r269270, reverted due to
https://llvm.org/bugs/show_bug.cgi?id=27725. Isolate the testcase that
corresponds to the new feature side of this commit and skip it on
windows hosts until we find why it does not work on these platforms.
Original commit message:
The way we currently build the internal VFS overlay representation leads
to inefficient path search and might yield wrong answers when asked for
recursive or regular directory iteration.
Currently, when reading an YAML file, each YAML root entry is placed
inside a new root in the filesystem overlay. In the crash reproducer, a
simple "@import Foundation" currently maps to 43 roots, and when looking
up paths, we traverse a directory tree for each of these different
roots, until we find a match (or don't). This has two consequences:
- It's slow.
- Directory iteration gives incomplete results since it only return
results within one root - since contents of the same directory can be
declared inside different roots, the result isn't accurate.
This is in part fault of the way we currently write out the YAML file
when emitting the crash reproducer - we could generate only one root and
that would make it fast and correct again. However, we should not rely
on how the client writes the YAML, but provide a good internal
representation regardless.
Build a proper virtual directory tree out of the YAML representation,
allowing faster search and proper iteration. Besides the crash
reproducer, this potentially benefits other VFS clients.
llvm-svn: 269327
2016-05-13 03:13:07 +08:00
|
|
|
StringRef Name = SrcE->getName();
|
|
|
|
switch (SrcE->getKind()) {
|
2019-01-16 06:36:41 +08:00
|
|
|
case RedirectingFileSystem::EK_Directory: {
|
2019-10-01 19:25:29 +08:00
|
|
|
auto *DE = cast<RedirectingFileSystem::RedirectingDirectoryEntry>(SrcE);
|
[VFS] Reapply #2: Reconstruct the VFS overlay tree for more accurate lookup
Reapply r269100 and r269270, reverted due to
https://llvm.org/bugs/show_bug.cgi?id=27725. Isolate the testcase that
corresponds to the new feature side of this commit and skip it on
windows hosts until we find why it does not work on these platforms.
Original commit message:
The way we currently build the internal VFS overlay representation leads
to inefficient path search and might yield wrong answers when asked for
recursive or regular directory iteration.
Currently, when reading an YAML file, each YAML root entry is placed
inside a new root in the filesystem overlay. In the crash reproducer, a
simple "@import Foundation" currently maps to 43 roots, and when looking
up paths, we traverse a directory tree for each of these different
roots, until we find a match (or don't). This has two consequences:
- It's slow.
- Directory iteration gives incomplete results since it only return
results within one root - since contents of the same directory can be
declared inside different roots, the result isn't accurate.
This is in part fault of the way we currently write out the YAML file
when emitting the crash reproducer - we could generate only one root and
that would make it fast and correct again. However, we should not rely
on how the client writes the YAML, but provide a good internal
representation regardless.
Build a proper virtual directory tree out of the YAML representation,
allowing faster search and proper iteration. Besides the crash
reproducer, this potentially benefits other VFS clients.
llvm-svn: 269327
2016-05-13 03:13:07 +08:00
|
|
|
// Empty directories could be present in the YAML as a way to
|
|
|
|
// describe a file for a current directory after some of its subdir
|
|
|
|
// is parsed. This only leads to redundant walks, ignore it.
|
|
|
|
if (!Name.empty())
|
|
|
|
NewParentE = lookupOrCreateEntry(FS, Name, NewParentE);
|
2019-01-16 06:36:41 +08:00
|
|
|
for (std::unique_ptr<RedirectingFileSystem::Entry> &SubEntry :
|
[VFS] Reapply #2: Reconstruct the VFS overlay tree for more accurate lookup
Reapply r269100 and r269270, reverted due to
https://llvm.org/bugs/show_bug.cgi?id=27725. Isolate the testcase that
corresponds to the new feature side of this commit and skip it on
windows hosts until we find why it does not work on these platforms.
Original commit message:
The way we currently build the internal VFS overlay representation leads
to inefficient path search and might yield wrong answers when asked for
recursive or regular directory iteration.
Currently, when reading an YAML file, each YAML root entry is placed
inside a new root in the filesystem overlay. In the crash reproducer, a
simple "@import Foundation" currently maps to 43 roots, and when looking
up paths, we traverse a directory tree for each of these different
roots, until we find a match (or don't). This has two consequences:
- It's slow.
- Directory iteration gives incomplete results since it only return
results within one root - since contents of the same directory can be
declared inside different roots, the result isn't accurate.
This is in part fault of the way we currently write out the YAML file
when emitting the crash reproducer - we could generate only one root and
that would make it fast and correct again. However, we should not rely
on how the client writes the YAML, but provide a good internal
representation regardless.
Build a proper virtual directory tree out of the YAML representation,
allowing faster search and proper iteration. Besides the crash
reproducer, this potentially benefits other VFS clients.
llvm-svn: 269327
2016-05-13 03:13:07 +08:00
|
|
|
llvm::make_range(DE->contents_begin(), DE->contents_end()))
|
|
|
|
uniqueOverlayTree(FS, SubEntry.get(), NewParentE);
|
|
|
|
break;
|
|
|
|
}
|
2019-01-16 06:36:41 +08:00
|
|
|
case RedirectingFileSystem::EK_File: {
|
[VFS] Reapply #2: Reconstruct the VFS overlay tree for more accurate lookup
Reapply r269100 and r269270, reverted due to
https://llvm.org/bugs/show_bug.cgi?id=27725. Isolate the testcase that
corresponds to the new feature side of this commit and skip it on
windows hosts until we find why it does not work on these platforms.
Original commit message:
The way we currently build the internal VFS overlay representation leads
to inefficient path search and might yield wrong answers when asked for
recursive or regular directory iteration.
Currently, when reading an YAML file, each YAML root entry is placed
inside a new root in the filesystem overlay. In the crash reproducer, a
simple "@import Foundation" currently maps to 43 roots, and when looking
up paths, we traverse a directory tree for each of these different
roots, until we find a match (or don't). This has two consequences:
- It's slow.
- Directory iteration gives incomplete results since it only return
results within one root - since contents of the same directory can be
declared inside different roots, the result isn't accurate.
This is in part fault of the way we currently write out the YAML file
when emitting the crash reproducer - we could generate only one root and
that would make it fast and correct again. However, we should not rely
on how the client writes the YAML, but provide a good internal
representation regardless.
Build a proper virtual directory tree out of the YAML representation,
allowing faster search and proper iteration. Besides the crash
reproducer, this potentially benefits other VFS clients.
llvm-svn: 269327
2016-05-13 03:13:07 +08:00
|
|
|
assert(NewParentE && "Parent entry must exist");
|
2019-10-01 19:25:29 +08:00
|
|
|
auto *FE = cast<RedirectingFileSystem::RedirectingFileEntry>(SrcE);
|
|
|
|
auto *DE =
|
|
|
|
cast<RedirectingFileSystem::RedirectingDirectoryEntry>(NewParentE);
|
2019-01-16 06:36:41 +08:00
|
|
|
DE->addContent(
|
2019-08-15 23:54:37 +08:00
|
|
|
std::make_unique<RedirectingFileSystem::RedirectingFileEntry>(
|
2019-01-16 06:36:41 +08:00
|
|
|
Name, FE->getExternalContentsPath(), FE->getUseName()));
|
[VFS] Reapply #2: Reconstruct the VFS overlay tree for more accurate lookup
Reapply r269100 and r269270, reverted due to
https://llvm.org/bugs/show_bug.cgi?id=27725. Isolate the testcase that
corresponds to the new feature side of this commit and skip it on
windows hosts until we find why it does not work on these platforms.
Original commit message:
The way we currently build the internal VFS overlay representation leads
to inefficient path search and might yield wrong answers when asked for
recursive or regular directory iteration.
Currently, when reading an YAML file, each YAML root entry is placed
inside a new root in the filesystem overlay. In the crash reproducer, a
simple "@import Foundation" currently maps to 43 roots, and when looking
up paths, we traverse a directory tree for each of these different
roots, until we find a match (or don't). This has two consequences:
- It's slow.
- Directory iteration gives incomplete results since it only return
results within one root - since contents of the same directory can be
declared inside different roots, the result isn't accurate.
This is in part fault of the way we currently write out the YAML file
when emitting the crash reproducer - we could generate only one root and
that would make it fast and correct again. However, we should not rely
on how the client writes the YAML, but provide a good internal
representation regardless.
Build a proper virtual directory tree out of the YAML representation,
allowing faster search and proper iteration. Besides the crash
reproducer, this potentially benefits other VFS clients.
llvm-svn: 269327
2016-05-13 03:13:07 +08:00
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2019-01-16 06:36:41 +08:00
|
|
|
std::unique_ptr<RedirectingFileSystem::Entry>
|
|
|
|
parseEntry(yaml::Node *N, RedirectingFileSystem *FS, bool IsRootEntry) {
|
2018-03-29 06:09:09 +08:00
|
|
|
auto *M = dyn_cast<yaml::MappingNode>(N);
|
2014-02-22 07:39:37 +08:00
|
|
|
if (!M) {
|
|
|
|
error(N, "expected mapping node for file or directory entry");
|
2014-05-08 14:41:40 +08:00
|
|
|
return nullptr;
|
2014-02-22 07:39:37 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
KeyStatusPair Fields[] = {
|
2018-10-10 21:27:25 +08:00
|
|
|
KeyStatusPair("name", true),
|
|
|
|
KeyStatusPair("type", true),
|
|
|
|
KeyStatusPair("contents", false),
|
|
|
|
KeyStatusPair("external-contents", false),
|
|
|
|
KeyStatusPair("use-external-name", false),
|
2014-02-22 07:39:37 +08:00
|
|
|
};
|
|
|
|
|
2015-11-30 11:11:10 +08:00
|
|
|
DenseMap<StringRef, KeyStatus> Keys(std::begin(Fields), std::end(Fields));
|
2014-02-22 07:39:37 +08:00
|
|
|
|
|
|
|
bool HasContents = false; // external or otherwise
|
2019-01-16 06:36:41 +08:00
|
|
|
std::vector<std::unique_ptr<RedirectingFileSystem::Entry>>
|
|
|
|
EntryArrayContents;
|
2020-01-22 08:45:51 +08:00
|
|
|
SmallString<256> ExternalContentsPath;
|
|
|
|
SmallString<256> Name;
|
2019-05-22 19:20:52 +08:00
|
|
|
yaml::Node *NameValueNode = nullptr;
|
2019-01-16 06:36:41 +08:00
|
|
|
auto UseExternalName =
|
|
|
|
RedirectingFileSystem::RedirectingFileEntry::NK_NotSet;
|
|
|
|
RedirectingFileSystem::EntryKind Kind;
|
2014-02-22 07:39:37 +08:00
|
|
|
|
2018-03-29 06:09:09 +08:00
|
|
|
for (auto &I : *M) {
|
2014-02-22 07:39:37 +08:00
|
|
|
StringRef Key;
|
|
|
|
// Reuse the buffer for key and value, since we don't look at key after
|
|
|
|
// parsing value.
|
|
|
|
SmallString<256> Buffer;
|
2018-03-29 06:09:09 +08:00
|
|
|
if (!parseScalarString(I.getKey(), Key, Buffer))
|
2014-05-08 14:41:40 +08:00
|
|
|
return nullptr;
|
2014-02-22 07:39:37 +08:00
|
|
|
|
2018-03-29 06:09:09 +08:00
|
|
|
if (!checkDuplicateOrUnknownKey(I.getKey(), Key, Keys))
|
2014-05-08 14:41:40 +08:00
|
|
|
return nullptr;
|
2014-02-22 07:39:37 +08:00
|
|
|
|
|
|
|
StringRef Value;
|
|
|
|
if (Key == "name") {
|
2018-03-29 06:09:09 +08:00
|
|
|
if (!parseScalarString(I.getValue(), Value, Buffer))
|
2014-05-08 14:41:40 +08:00
|
|
|
return nullptr;
|
2016-03-17 10:20:43 +08:00
|
|
|
|
2018-08-08 03:05:41 +08:00
|
|
|
NameValueNode = I.getValue();
|
2020-01-22 08:45:51 +08:00
|
|
|
// Guarantee that old YAML files containing paths with ".." and "."
|
|
|
|
// are properly canonicalized before read into the VFS.
|
|
|
|
Name = canonicalize(Value).str();
|
2014-02-22 07:39:37 +08:00
|
|
|
} else if (Key == "type") {
|
2018-03-29 06:09:09 +08:00
|
|
|
if (!parseScalarString(I.getValue(), Value, Buffer))
|
2014-05-08 14:41:40 +08:00
|
|
|
return nullptr;
|
2014-02-22 07:39:37 +08:00
|
|
|
if (Value == "file")
|
2019-01-16 06:36:41 +08:00
|
|
|
Kind = RedirectingFileSystem::EK_File;
|
2014-02-22 07:39:37 +08:00
|
|
|
else if (Value == "directory")
|
2019-01-16 06:36:41 +08:00
|
|
|
Kind = RedirectingFileSystem::EK_Directory;
|
2014-02-22 07:39:37 +08:00
|
|
|
else {
|
2018-03-29 06:09:09 +08:00
|
|
|
error(I.getValue(), "unknown value for 'type'");
|
2014-05-08 14:41:40 +08:00
|
|
|
return nullptr;
|
2014-02-22 07:39:37 +08:00
|
|
|
}
|
|
|
|
} else if (Key == "contents") {
|
|
|
|
if (HasContents) {
|
2018-03-29 06:09:09 +08:00
|
|
|
error(I.getKey(),
|
2014-02-22 07:39:37 +08:00
|
|
|
"entry already has 'contents' or 'external-contents'");
|
2014-05-08 14:41:40 +08:00
|
|
|
return nullptr;
|
2014-02-22 07:39:37 +08:00
|
|
|
}
|
|
|
|
HasContents = true;
|
2018-03-29 06:09:09 +08:00
|
|
|
auto *Contents = dyn_cast<yaml::SequenceNode>(I.getValue());
|
2014-02-22 07:39:37 +08:00
|
|
|
if (!Contents) {
|
|
|
|
// FIXME: this is only for directories, what about files?
|
2018-03-29 06:09:09 +08:00
|
|
|
error(I.getValue(), "expected array");
|
2014-05-08 14:41:40 +08:00
|
|
|
return nullptr;
|
2014-02-22 07:39:37 +08:00
|
|
|
}
|
|
|
|
|
2018-03-29 06:09:09 +08:00
|
|
|
for (auto &I : *Contents) {
|
2019-01-16 06:36:41 +08:00
|
|
|
if (std::unique_ptr<RedirectingFileSystem::Entry> E =
|
2018-08-08 03:05:41 +08:00
|
|
|
parseEntry(&I, FS, /*IsRootEntry*/ false))
|
2015-10-07 18:05:44 +08:00
|
|
|
EntryArrayContents.push_back(std::move(E));
|
2014-02-22 07:39:37 +08:00
|
|
|
else
|
2014-05-08 14:41:40 +08:00
|
|
|
return nullptr;
|
2014-02-22 07:39:37 +08:00
|
|
|
}
|
|
|
|
} else if (Key == "external-contents") {
|
|
|
|
if (HasContents) {
|
2018-03-29 06:09:09 +08:00
|
|
|
error(I.getKey(),
|
2014-02-22 07:39:37 +08:00
|
|
|
"entry already has 'contents' or 'external-contents'");
|
2014-05-08 14:41:40 +08:00
|
|
|
return nullptr;
|
2014-02-22 07:39:37 +08:00
|
|
|
}
|
|
|
|
HasContents = true;
|
2018-03-29 06:09:09 +08:00
|
|
|
if (!parseScalarString(I.getValue(), Value, Buffer))
|
2014-05-08 14:41:40 +08:00
|
|
|
return nullptr;
|
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
|
|
|
|
|
|
|
SmallString<256> FullPath;
|
|
|
|
if (FS->IsRelativeOverlay) {
|
|
|
|
FullPath = FS->getExternalContentsPrefixDir();
|
|
|
|
assert(!FullPath.empty() &&
|
|
|
|
"External contents prefix directory must exist");
|
|
|
|
llvm::sys::path::append(FullPath, Value);
|
|
|
|
} else {
|
|
|
|
FullPath = Value;
|
|
|
|
}
|
|
|
|
|
2020-01-22 08:45:51 +08:00
|
|
|
// Guarantee that old YAML files containing paths with ".." and "."
|
|
|
|
// are properly canonicalized before read into the VFS.
|
|
|
|
FullPath = canonicalize(FullPath);
|
|
|
|
ExternalContentsPath = FullPath.str();
|
2014-02-27 08:25:12 +08:00
|
|
|
} else if (Key == "use-external-name") {
|
|
|
|
bool Val;
|
2018-03-29 06:09:09 +08:00
|
|
|
if (!parseScalarBool(I.getValue(), Val))
|
2014-05-08 14:41:40 +08:00
|
|
|
return nullptr;
|
2019-01-16 06:36:41 +08:00
|
|
|
UseExternalName =
|
|
|
|
Val ? RedirectingFileSystem::RedirectingFileEntry::NK_External
|
|
|
|
: RedirectingFileSystem::RedirectingFileEntry::NK_Virtual;
|
2014-02-22 07:39:37 +08:00
|
|
|
} else {
|
|
|
|
llvm_unreachable("key missing from Keys");
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
if (Stream.failed())
|
2014-05-08 14:41:40 +08:00
|
|
|
return nullptr;
|
2014-02-22 07:39:37 +08:00
|
|
|
|
|
|
|
// check for missing keys
|
|
|
|
if (!HasContents) {
|
|
|
|
error(N, "missing key 'contents' or 'external-contents'");
|
2014-05-08 14:41:40 +08:00
|
|
|
return nullptr;
|
2014-02-22 07:39:37 +08:00
|
|
|
}
|
|
|
|
if (!checkMissingKeys(N, Keys))
|
2014-05-08 14:41:40 +08:00
|
|
|
return nullptr;
|
2014-02-22 07:39:37 +08:00
|
|
|
|
2014-02-27 08:25:12 +08:00
|
|
|
// check invalid configuration
|
2019-01-16 06:36:41 +08:00
|
|
|
if (Kind == RedirectingFileSystem::EK_Directory &&
|
|
|
|
UseExternalName !=
|
|
|
|
RedirectingFileSystem::RedirectingFileEntry::NK_NotSet) {
|
2014-02-27 08:25:12 +08:00
|
|
|
error(N, "'use-external-name' is not supported for directories");
|
2014-05-08 14:41:40 +08:00
|
|
|
return nullptr;
|
2014-02-27 08:25:12 +08:00
|
|
|
}
|
|
|
|
|
2019-11-26 07:57:21 +08:00
|
|
|
sys::path::Style path_style = sys::path::Style::native;
|
|
|
|
if (IsRootEntry) {
|
|
|
|
// VFS root entries may be in either Posix or Windows style. Figure out
|
|
|
|
// which style we have, and use it consistently.
|
|
|
|
if (sys::path::is_absolute(Name, sys::path::Style::posix)) {
|
|
|
|
path_style = sys::path::Style::posix;
|
|
|
|
} else if (sys::path::is_absolute(Name, sys::path::Style::windows)) {
|
|
|
|
path_style = sys::path::Style::windows;
|
|
|
|
} else {
|
|
|
|
assert(NameValueNode && "Name presence should be checked earlier");
|
|
|
|
error(NameValueNode,
|
|
|
|
"entry with relative path at the root level is not discoverable");
|
|
|
|
return nullptr;
|
|
|
|
}
|
2018-08-08 03:05:41 +08:00
|
|
|
}
|
|
|
|
|
2014-03-06 05:32:20 +08:00
|
|
|
// Remove trailing slash(es), being careful not to remove the root path
|
2014-02-25 12:34:14 +08:00
|
|
|
StringRef Trimmed(Name);
|
2019-11-26 07:57:21 +08:00
|
|
|
size_t RootPathLen = sys::path::root_path(Trimmed, path_style).size();
|
2014-03-06 05:32:20 +08:00
|
|
|
while (Trimmed.size() > RootPathLen &&
|
2019-11-26 07:57:21 +08:00
|
|
|
sys::path::is_separator(Trimmed.back(), path_style))
|
2018-10-10 21:27:25 +08:00
|
|
|
Trimmed = Trimmed.slice(0, Trimmed.size() - 1);
|
2019-11-26 07:57:21 +08:00
|
|
|
|
2014-02-25 12:34:14 +08:00
|
|
|
// Get the last component
|
2019-11-26 07:57:21 +08:00
|
|
|
StringRef LastComponent = sys::path::filename(Trimmed, path_style);
|
2014-02-25 12:34:14 +08:00
|
|
|
|
2019-01-16 06:36:41 +08:00
|
|
|
std::unique_ptr<RedirectingFileSystem::Entry> Result;
|
2014-02-22 07:39:37 +08:00
|
|
|
switch (Kind) {
|
2019-01-16 06:36:41 +08:00
|
|
|
case RedirectingFileSystem::EK_File:
|
2019-08-15 23:54:37 +08:00
|
|
|
Result = std::make_unique<RedirectingFileSystem::RedirectingFileEntry>(
|
2015-10-07 18:05:44 +08:00
|
|
|
LastComponent, std::move(ExternalContentsPath), UseExternalName);
|
2014-02-25 12:34:14 +08:00
|
|
|
break;
|
2019-01-16 06:36:41 +08:00
|
|
|
case RedirectingFileSystem::EK_Directory:
|
|
|
|
Result =
|
2019-08-15 23:54:37 +08:00
|
|
|
std::make_unique<RedirectingFileSystem::RedirectingDirectoryEntry>(
|
2019-01-16 06:36:41 +08:00
|
|
|
LastComponent, std::move(EntryArrayContents),
|
|
|
|
Status("", getNextVirtualUniqueID(),
|
|
|
|
std::chrono::system_clock::now(), 0, 0, 0,
|
|
|
|
file_type::directory_file, sys::fs::all_all));
|
2014-02-25 12:34:14 +08:00
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
2019-11-26 07:57:21 +08:00
|
|
|
StringRef Parent = sys::path::parent_path(Trimmed, path_style);
|
2014-02-25 12:34:14 +08:00
|
|
|
if (Parent.empty())
|
|
|
|
return Result;
|
|
|
|
|
|
|
|
// if 'name' contains multiple components, create implicit directory entries
|
2019-11-26 07:57:21 +08:00
|
|
|
for (sys::path::reverse_iterator I = sys::path::rbegin(Parent, path_style),
|
2014-02-25 12:34:14 +08:00
|
|
|
E = sys::path::rend(Parent);
|
|
|
|
I != E; ++I) {
|
2019-01-16 06:36:41 +08:00
|
|
|
std::vector<std::unique_ptr<RedirectingFileSystem::Entry>> Entries;
|
2015-10-07 18:05:44 +08:00
|
|
|
Entries.push_back(std::move(Result));
|
2019-01-16 06:36:41 +08:00
|
|
|
Result =
|
2019-08-15 23:54:37 +08:00
|
|
|
std::make_unique<RedirectingFileSystem::RedirectingDirectoryEntry>(
|
2019-01-16 06:36:41 +08:00
|
|
|
*I, std::move(Entries),
|
|
|
|
Status("", getNextVirtualUniqueID(),
|
|
|
|
std::chrono::system_clock::now(), 0, 0, 0,
|
|
|
|
file_type::directory_file, sys::fs::all_all));
|
2014-02-22 07:39:37 +08:00
|
|
|
}
|
2014-02-25 12:34:14 +08:00
|
|
|
return Result;
|
2014-02-22 07:39:37 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
public:
|
2015-10-07 18:05:44 +08:00
|
|
|
RedirectingFileSystemParser(yaml::Stream &S) : Stream(S) {}
|
2014-02-22 07:39:37 +08:00
|
|
|
|
|
|
|
// false on error
|
2015-10-07 18:05:44 +08:00
|
|
|
bool parse(yaml::Node *Root, RedirectingFileSystem *FS) {
|
2018-03-29 06:09:09 +08:00
|
|
|
auto *Top = dyn_cast<yaml::MappingNode>(Root);
|
2014-02-22 07:39:37 +08:00
|
|
|
if (!Top) {
|
|
|
|
error(Root, "expected mapping node");
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
|
|
|
KeyStatusPair Fields[] = {
|
2018-10-10 21:27:25 +08:00
|
|
|
KeyStatusPair("version", true),
|
|
|
|
KeyStatusPair("case-sensitive", false),
|
|
|
|
KeyStatusPair("use-external-names", false),
|
|
|
|
KeyStatusPair("overlay-relative", false),
|
2018-10-27 06:14:33 +08:00
|
|
|
KeyStatusPair("fallthrough", false),
|
2018-10-10 21:27:25 +08:00
|
|
|
KeyStatusPair("roots", true),
|
2014-02-22 07:39:37 +08:00
|
|
|
};
|
|
|
|
|
2015-11-30 11:11:10 +08:00
|
|
|
DenseMap<StringRef, KeyStatus> Keys(std::begin(Fields), std::end(Fields));
|
2019-01-16 06:36:41 +08:00
|
|
|
std::vector<std::unique_ptr<RedirectingFileSystem::Entry>> RootEntries;
|
2014-02-22 07:39:37 +08:00
|
|
|
|
|
|
|
// Parse configuration and 'roots'
|
2018-03-29 06:09:09 +08:00
|
|
|
for (auto &I : *Top) {
|
2014-02-22 07:39:37 +08:00
|
|
|
SmallString<10> KeyBuffer;
|
|
|
|
StringRef Key;
|
2018-03-29 06:09:09 +08:00
|
|
|
if (!parseScalarString(I.getKey(), Key, KeyBuffer))
|
2014-02-22 07:39:37 +08:00
|
|
|
return false;
|
|
|
|
|
2018-03-29 06:09:09 +08:00
|
|
|
if (!checkDuplicateOrUnknownKey(I.getKey(), Key, Keys))
|
2014-02-22 07:39:37 +08:00
|
|
|
return false;
|
|
|
|
|
|
|
|
if (Key == "roots") {
|
2018-03-29 06:09:09 +08:00
|
|
|
auto *Roots = dyn_cast<yaml::SequenceNode>(I.getValue());
|
2014-02-22 07:39:37 +08:00
|
|
|
if (!Roots) {
|
2018-03-29 06:09:09 +08:00
|
|
|
error(I.getValue(), "expected array");
|
2014-02-22 07:39:37 +08:00
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
2018-03-29 06:09:09 +08:00
|
|
|
for (auto &I : *Roots) {
|
2019-01-16 06:36:41 +08:00
|
|
|
if (std::unique_ptr<RedirectingFileSystem::Entry> E =
|
2018-08-08 03:05:41 +08:00
|
|
|
parseEntry(&I, FS, /*IsRootEntry*/ true))
|
[VFS] Reapply #2: Reconstruct the VFS overlay tree for more accurate lookup
Reapply r269100 and r269270, reverted due to
https://llvm.org/bugs/show_bug.cgi?id=27725. Isolate the testcase that
corresponds to the new feature side of this commit and skip it on
windows hosts until we find why it does not work on these platforms.
Original commit message:
The way we currently build the internal VFS overlay representation leads
to inefficient path search and might yield wrong answers when asked for
recursive or regular directory iteration.
Currently, when reading an YAML file, each YAML root entry is placed
inside a new root in the filesystem overlay. In the crash reproducer, a
simple "@import Foundation" currently maps to 43 roots, and when looking
up paths, we traverse a directory tree for each of these different
roots, until we find a match (or don't). This has two consequences:
- It's slow.
- Directory iteration gives incomplete results since it only return
results within one root - since contents of the same directory can be
declared inside different roots, the result isn't accurate.
This is in part fault of the way we currently write out the YAML file
when emitting the crash reproducer - we could generate only one root and
that would make it fast and correct again. However, we should not rely
on how the client writes the YAML, but provide a good internal
representation regardless.
Build a proper virtual directory tree out of the YAML representation,
allowing faster search and proper iteration. Besides the crash
reproducer, this potentially benefits other VFS clients.
llvm-svn: 269327
2016-05-13 03:13:07 +08:00
|
|
|
RootEntries.push_back(std::move(E));
|
2014-02-22 07:39:37 +08:00
|
|
|
else
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
} else if (Key == "version") {
|
|
|
|
StringRef VersionString;
|
|
|
|
SmallString<4> Storage;
|
2018-03-29 06:09:09 +08:00
|
|
|
if (!parseScalarString(I.getValue(), VersionString, Storage))
|
2014-02-22 07:39:37 +08:00
|
|
|
return false;
|
|
|
|
int Version;
|
|
|
|
if (VersionString.getAsInteger<int>(10, Version)) {
|
2018-03-29 06:09:09 +08:00
|
|
|
error(I.getValue(), "expected integer");
|
2014-02-22 07:39:37 +08:00
|
|
|
return false;
|
|
|
|
}
|
|
|
|
if (Version < 0) {
|
2018-03-29 06:09:09 +08:00
|
|
|
error(I.getValue(), "invalid version number");
|
2014-02-22 07:39:37 +08:00
|
|
|
return false;
|
|
|
|
}
|
|
|
|
if (Version != 0) {
|
2018-03-29 06:09:09 +08:00
|
|
|
error(I.getValue(), "version mismatch, expected 0");
|
2014-02-22 07:39:37 +08:00
|
|
|
return false;
|
|
|
|
}
|
|
|
|
} else if (Key == "case-sensitive") {
|
2018-03-29 06:09:09 +08:00
|
|
|
if (!parseScalarBool(I.getValue(), FS->CaseSensitive))
|
2014-02-22 07:39:37 +08:00
|
|
|
return false;
|
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
|
|
|
} else if (Key == "overlay-relative") {
|
2018-03-29 06:09:09 +08:00
|
|
|
if (!parseScalarBool(I.getValue(), FS->IsRelativeOverlay))
|
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
|
|
|
return false;
|
2014-02-27 08:25:12 +08:00
|
|
|
} else if (Key == "use-external-names") {
|
2018-03-29 06:09:09 +08:00
|
|
|
if (!parseScalarBool(I.getValue(), FS->UseExternalNames))
|
2014-02-27 08:25:12 +08:00
|
|
|
return false;
|
2018-10-27 06:14:33 +08:00
|
|
|
} else if (Key == "fallthrough") {
|
|
|
|
if (!parseScalarBool(I.getValue(), FS->IsFallthrough))
|
|
|
|
return false;
|
2014-02-22 07:39:37 +08:00
|
|
|
} else {
|
|
|
|
llvm_unreachable("key missing from Keys");
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
if (Stream.failed())
|
|
|
|
return false;
|
|
|
|
|
|
|
|
if (!checkMissingKeys(Top, Keys))
|
|
|
|
return false;
|
[VFS] Reapply #2: Reconstruct the VFS overlay tree for more accurate lookup
Reapply r269100 and r269270, reverted due to
https://llvm.org/bugs/show_bug.cgi?id=27725. Isolate the testcase that
corresponds to the new feature side of this commit and skip it on
windows hosts until we find why it does not work on these platforms.
Original commit message:
The way we currently build the internal VFS overlay representation leads
to inefficient path search and might yield wrong answers when asked for
recursive or regular directory iteration.
Currently, when reading an YAML file, each YAML root entry is placed
inside a new root in the filesystem overlay. In the crash reproducer, a
simple "@import Foundation" currently maps to 43 roots, and when looking
up paths, we traverse a directory tree for each of these different
roots, until we find a match (or don't). This has two consequences:
- It's slow.
- Directory iteration gives incomplete results since it only return
results within one root - since contents of the same directory can be
declared inside different roots, the result isn't accurate.
This is in part fault of the way we currently write out the YAML file
when emitting the crash reproducer - we could generate only one root and
that would make it fast and correct again. However, we should not rely
on how the client writes the YAML, but provide a good internal
representation regardless.
Build a proper virtual directory tree out of the YAML representation,
allowing faster search and proper iteration. Besides the crash
reproducer, this potentially benefits other VFS clients.
llvm-svn: 269327
2016-05-13 03:13:07 +08:00
|
|
|
|
|
|
|
// Now that we sucessefully parsed the YAML file, canonicalize the internal
|
|
|
|
// representation to a proper directory tree so that we can search faster
|
|
|
|
// inside the VFS.
|
2018-03-29 06:09:09 +08:00
|
|
|
for (auto &E : RootEntries)
|
[VFS] Reapply #2: Reconstruct the VFS overlay tree for more accurate lookup
Reapply r269100 and r269270, reverted due to
https://llvm.org/bugs/show_bug.cgi?id=27725. Isolate the testcase that
corresponds to the new feature side of this commit and skip it on
windows hosts until we find why it does not work on these platforms.
Original commit message:
The way we currently build the internal VFS overlay representation leads
to inefficient path search and might yield wrong answers when asked for
recursive or regular directory iteration.
Currently, when reading an YAML file, each YAML root entry is placed
inside a new root in the filesystem overlay. In the crash reproducer, a
simple "@import Foundation" currently maps to 43 roots, and when looking
up paths, we traverse a directory tree for each of these different
roots, until we find a match (or don't). This has two consequences:
- It's slow.
- Directory iteration gives incomplete results since it only return
results within one root - since contents of the same directory can be
declared inside different roots, the result isn't accurate.
This is in part fault of the way we currently write out the YAML file
when emitting the crash reproducer - we could generate only one root and
that would make it fast and correct again. However, we should not rely
on how the client writes the YAML, but provide a good internal
representation regardless.
Build a proper virtual directory tree out of the YAML representation,
allowing faster search and proper iteration. Besides the crash
reproducer, this potentially benefits other VFS clients.
llvm-svn: 269327
2016-05-13 03:13:07 +08:00
|
|
|
uniqueOverlayTree(FS, E.get());
|
|
|
|
|
2014-02-22 07:39:37 +08:00
|
|
|
return true;
|
|
|
|
}
|
|
|
|
};
|
|
|
|
|
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
|
|
|
RedirectingFileSystem *
|
|
|
|
RedirectingFileSystem::create(std::unique_ptr<MemoryBuffer> Buffer,
|
|
|
|
SourceMgr::DiagHandlerTy DiagHandler,
|
|
|
|
StringRef YAMLFilePath, void *DiagContext,
|
|
|
|
IntrusiveRefCntPtr<FileSystem> ExternalFS) {
|
2014-02-22 07:39:37 +08:00
|
|
|
SourceMgr SM;
|
2014-08-28 03:03:27 +08:00
|
|
|
yaml::Stream Stream(Buffer->getMemBufferRef(), SM);
|
2014-02-22 07:39:37 +08:00
|
|
|
|
2014-02-25 04:56:37 +08:00
|
|
|
SM.setDiagHandler(DiagHandler, DiagContext);
|
2014-02-22 07:39:37 +08:00
|
|
|
yaml::document_iterator DI = Stream.begin();
|
|
|
|
yaml::Node *Root = DI->getRoot();
|
|
|
|
if (DI == Stream.end() || !Root) {
|
|
|
|
SM.PrintMessage(SMLoc(), SourceMgr::DK_Error, "expected root node");
|
2014-05-08 14:41:40 +08:00
|
|
|
return nullptr;
|
2014-02-22 07:39:37 +08:00
|
|
|
}
|
|
|
|
|
2015-10-07 18:05:44 +08:00
|
|
|
RedirectingFileSystemParser P(Stream);
|
2014-02-22 07:39:37 +08:00
|
|
|
|
2015-10-07 18:05:44 +08:00
|
|
|
std::unique_ptr<RedirectingFileSystem> FS(
|
2019-10-16 07:08:57 +08:00
|
|
|
new RedirectingFileSystem(ExternalFS));
|
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
|
|
|
|
|
|
|
if (!YAMLFilePath.empty()) {
|
|
|
|
// Use the YAML path from -ivfsoverlay to compute the dir to be prefixed
|
|
|
|
// to each 'external-contents' path.
|
|
|
|
//
|
|
|
|
// Example:
|
|
|
|
// -ivfsoverlay dummy.cache/vfs/vfs.yaml
|
|
|
|
// yields:
|
|
|
|
// FS->ExternalContentsPrefixDir => /<absolute_path_to>/dummy.cache/vfs
|
|
|
|
//
|
|
|
|
SmallString<256> OverlayAbsDir = sys::path::parent_path(YAMLFilePath);
|
|
|
|
std::error_code EC = llvm::sys::fs::make_absolute(OverlayAbsDir);
|
|
|
|
assert(!EC && "Overlay dir final path must be absolute");
|
|
|
|
(void)EC;
|
|
|
|
FS->setExternalContentsPrefixDir(OverlayAbsDir);
|
|
|
|
}
|
|
|
|
|
2014-02-22 07:39:37 +08:00
|
|
|
if (!P.parse(Root, FS.get()))
|
2014-05-08 14:41:40 +08:00
|
|
|
return nullptr;
|
2014-02-22 07:39:37 +08:00
|
|
|
|
2014-03-08 03:33:25 +08:00
|
|
|
return FS.release();
|
2014-02-22 07:39:37 +08:00
|
|
|
}
|
|
|
|
|
2019-01-16 06:36:41 +08:00
|
|
|
ErrorOr<RedirectingFileSystem::Entry *>
|
|
|
|
RedirectingFileSystem::lookupPath(const Twine &Path_) const {
|
2014-03-05 06:34:50 +08:00
|
|
|
SmallString<256> Path;
|
|
|
|
Path_.toVector(Path);
|
|
|
|
|
|
|
|
// Handle relative paths
|
2015-10-05 21:55:20 +08:00
|
|
|
if (std::error_code EC = makeAbsolute(Path))
|
2014-03-05 06:34:50 +08:00
|
|
|
return EC;
|
2014-02-22 07:39:37 +08:00
|
|
|
|
2020-01-22 08:45:51 +08:00
|
|
|
// Canonicalize path by removing ".", "..", "./", components. This is
|
|
|
|
// a VFS request, do not bother about symlinks in the path components
|
2016-03-17 10:20:43 +08:00
|
|
|
// but canonicalize in order to perform the correct entry search.
|
2020-01-22 08:45:51 +08:00
|
|
|
Path = canonicalize(Path);
|
2014-02-22 07:39:37 +08:00
|
|
|
if (Path.empty())
|
2014-06-14 01:20:50 +08:00
|
|
|
return make_error_code(llvm::errc::invalid_argument);
|
2014-02-22 07:39:37 +08:00
|
|
|
|
|
|
|
sys::path::const_iterator Start = sys::path::begin(Path);
|
|
|
|
sys::path::const_iterator End = sys::path::end(Path);
|
2018-03-29 06:09:09 +08:00
|
|
|
for (const auto &Root : Roots) {
|
2019-01-16 06:36:41 +08:00
|
|
|
ErrorOr<RedirectingFileSystem::Entry *> Result =
|
|
|
|
lookupPath(Start, End, Root.get());
|
2014-06-14 01:20:50 +08:00
|
|
|
if (Result || Result.getError() != llvm::errc::no_such_file_or_directory)
|
2014-02-22 07:39:37 +08:00
|
|
|
return Result;
|
|
|
|
}
|
2014-06-14 01:20:50 +08:00
|
|
|
return make_error_code(llvm::errc::no_such_file_or_directory);
|
2014-02-22 07:39:37 +08:00
|
|
|
}
|
|
|
|
|
2019-01-16 06:36:41 +08:00
|
|
|
ErrorOr<RedirectingFileSystem::Entry *>
|
2015-10-07 18:05:44 +08:00
|
|
|
RedirectingFileSystem::lookupPath(sys::path::const_iterator Start,
|
2018-11-16 09:15:54 +08:00
|
|
|
sys::path::const_iterator End,
|
2019-01-16 06:36:41 +08:00
|
|
|
RedirectingFileSystem::Entry *From) const {
|
2016-03-17 10:20:43 +08:00
|
|
|
assert(!isTraversalComponent(*Start) &&
|
|
|
|
!isTraversalComponent(From->getName()) &&
|
|
|
|
"Paths should not contain traversal components");
|
2014-03-05 06:34:50 +08:00
|
|
|
|
2016-03-31 07:54:00 +08:00
|
|
|
StringRef FromName = From->getName();
|
2014-02-22 07:39:37 +08:00
|
|
|
|
2016-03-31 07:54:00 +08:00
|
|
|
// Forward the search to the next component in case this is an empty one.
|
|
|
|
if (!FromName.empty()) {
|
2019-11-08 02:50:33 +08:00
|
|
|
if (!pathComponentMatches(*Start, FromName))
|
2016-03-31 07:54:00 +08:00
|
|
|
return make_error_code(llvm::errc::no_such_file_or_directory);
|
2014-02-22 07:39:37 +08:00
|
|
|
|
2016-03-31 07:54:00 +08:00
|
|
|
++Start;
|
|
|
|
|
|
|
|
if (Start == End) {
|
|
|
|
// Match!
|
|
|
|
return From;
|
|
|
|
}
|
2014-02-22 07:39:37 +08:00
|
|
|
}
|
|
|
|
|
2019-01-16 06:36:41 +08:00
|
|
|
auto *DE = dyn_cast<RedirectingFileSystem::RedirectingDirectoryEntry>(From);
|
2014-02-22 07:39:37 +08:00
|
|
|
if (!DE)
|
2014-06-14 01:20:50 +08:00
|
|
|
return make_error_code(llvm::errc::not_a_directory);
|
2014-02-22 07:39:37 +08:00
|
|
|
|
2019-01-16 06:36:41 +08:00
|
|
|
for (const std::unique_ptr<RedirectingFileSystem::Entry> &DirEntry :
|
2015-10-07 18:05:44 +08:00
|
|
|
llvm::make_range(DE->contents_begin(), DE->contents_end())) {
|
2019-01-16 06:36:41 +08:00
|
|
|
ErrorOr<RedirectingFileSystem::Entry *> Result =
|
|
|
|
lookupPath(Start, End, DirEntry.get());
|
2014-06-14 01:20:50 +08:00
|
|
|
if (Result || Result.getError() != llvm::errc::no_such_file_or_directory)
|
2014-02-22 07:39:37 +08:00
|
|
|
return Result;
|
|
|
|
}
|
2019-11-08 02:50:33 +08:00
|
|
|
|
2014-06-14 01:20:50 +08:00
|
|
|
return make_error_code(llvm::errc::no_such_file_or_directory);
|
2014-02-22 07:39:37 +08:00
|
|
|
}
|
|
|
|
|
2015-12-11 07:41:39 +08:00
|
|
|
static Status getRedirectedFileStatus(const Twine &Path, bool UseExternalNames,
|
|
|
|
Status ExternalStatus) {
|
|
|
|
Status S = ExternalStatus;
|
|
|
|
if (!UseExternalNames)
|
2019-02-24 07:48:47 +08:00
|
|
|
S = Status::copyWithNewName(S, Path);
|
2015-12-11 07:41:39 +08:00
|
|
|
S.IsVFSMapped = true;
|
|
|
|
return S;
|
|
|
|
}
|
|
|
|
|
2019-01-16 06:36:41 +08:00
|
|
|
ErrorOr<Status> RedirectingFileSystem::status(const Twine &Path,
|
|
|
|
RedirectingFileSystem::Entry *E) {
|
2014-06-25 03:37:16 +08:00
|
|
|
assert(E != nullptr);
|
2019-01-16 06:36:41 +08:00
|
|
|
if (auto *F = dyn_cast<RedirectingFileSystem::RedirectingFileEntry>(E)) {
|
2014-02-22 07:39:37 +08:00
|
|
|
ErrorOr<Status> S = ExternalFS->status(F->getExternalContentsPath());
|
2014-02-27 08:25:12 +08:00
|
|
|
assert(!S || S->getName() == F->getExternalContentsPath());
|
2014-05-24 02:15:47 +08:00
|
|
|
if (S)
|
2015-12-11 07:41:39 +08:00
|
|
|
return getRedirectedFileStatus(Path, F->useExternalName(UseExternalNames),
|
|
|
|
*S);
|
2014-02-22 07:39:37 +08:00
|
|
|
return S;
|
|
|
|
} else { // directory
|
2019-01-16 06:36:41 +08:00
|
|
|
auto *DE = cast<RedirectingFileSystem::RedirectingDirectoryEntry>(E);
|
2019-02-24 07:48:47 +08:00
|
|
|
return Status::copyWithNewName(DE->getStatus(), Path);
|
2014-02-22 07:39:37 +08:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2015-10-07 18:05:44 +08:00
|
|
|
ErrorOr<Status> RedirectingFileSystem::status(const Twine &Path) {
|
2019-01-16 06:36:41 +08:00
|
|
|
ErrorOr<RedirectingFileSystem::Entry *> Result = lookupPath(Path);
|
2018-10-27 06:14:33 +08:00
|
|
|
if (!Result) {
|
2019-10-16 07:08:57 +08:00
|
|
|
if (shouldUseExternalFS() &&
|
2018-10-27 06:14:33 +08:00
|
|
|
Result.getError() == llvm::errc::no_such_file_or_directory) {
|
|
|
|
return ExternalFS->status(Path);
|
|
|
|
}
|
2014-06-25 03:37:16 +08:00
|
|
|
return Result.getError();
|
2018-10-27 06:14:33 +08:00
|
|
|
}
|
2014-06-25 03:37:16 +08:00
|
|
|
return status(Path, *Result);
|
|
|
|
}
|
|
|
|
|
2015-10-05 21:55:09 +08:00
|
|
|
namespace {
|
2018-03-29 06:09:09 +08:00
|
|
|
|
2015-12-11 07:41:39 +08:00
|
|
|
/// Provide a file wrapper with an overriden status.
|
|
|
|
class FileWithFixedStatus : public File {
|
2015-10-05 21:55:09 +08:00
|
|
|
std::unique_ptr<File> InnerFile;
|
2015-12-11 07:41:39 +08:00
|
|
|
Status S;
|
2015-10-05 21:55:09 +08:00
|
|
|
|
|
|
|
public:
|
2015-12-11 07:41:39 +08:00
|
|
|
FileWithFixedStatus(std::unique_ptr<File> InnerFile, Status S)
|
2016-05-27 22:27:13 +08:00
|
|
|
: InnerFile(std::move(InnerFile)), S(std::move(S)) {}
|
2015-12-11 07:41:39 +08:00
|
|
|
|
|
|
|
ErrorOr<Status> status() override { return S; }
|
|
|
|
ErrorOr<std::unique_ptr<llvm::MemoryBuffer>>
|
2018-03-29 06:09:09 +08:00
|
|
|
|
2015-10-06 05:20:19 +08:00
|
|
|
getBuffer(const Twine &Name, int64_t FileSize, bool RequiresNullTerminator,
|
|
|
|
bool IsVolatile) override {
|
2015-10-05 21:55:09 +08:00
|
|
|
return InnerFile->getBuffer(Name, FileSize, RequiresNullTerminator,
|
|
|
|
IsVolatile);
|
|
|
|
}
|
2018-03-29 06:09:09 +08:00
|
|
|
|
2015-10-05 21:55:09 +08:00
|
|
|
std::error_code close() override { return InnerFile->close(); }
|
|
|
|
};
|
2018-03-29 06:09:09 +08:00
|
|
|
|
|
|
|
} // namespace
|
2015-10-05 21:55:09 +08:00
|
|
|
|
2015-10-07 18:05:44 +08:00
|
|
|
ErrorOr<std::unique_ptr<File>>
|
|
|
|
RedirectingFileSystem::openFileForRead(const Twine &Path) {
|
2019-01-16 06:36:41 +08:00
|
|
|
ErrorOr<RedirectingFileSystem::Entry *> E = lookupPath(Path);
|
2018-10-27 06:14:33 +08:00
|
|
|
if (!E) {
|
2019-10-16 19:17:08 +08:00
|
|
|
if (shouldUseExternalFS() &&
|
2018-10-27 06:14:33 +08:00
|
|
|
E.getError() == llvm::errc::no_such_file_or_directory) {
|
|
|
|
return ExternalFS->openFileForRead(Path);
|
|
|
|
}
|
2014-02-22 07:39:37 +08:00
|
|
|
return E.getError();
|
2018-10-27 06:14:33 +08:00
|
|
|
}
|
2014-02-22 07:39:37 +08:00
|
|
|
|
2019-01-16 06:36:41 +08:00
|
|
|
auto *F = dyn_cast<RedirectingFileSystem::RedirectingFileEntry>(*E);
|
2014-02-22 07:39:37 +08:00
|
|
|
if (!F) // FIXME: errc::not_a_file?
|
2014-06-14 01:20:50 +08:00
|
|
|
return make_error_code(llvm::errc::invalid_argument);
|
2014-02-22 07:39:37 +08:00
|
|
|
|
2014-10-27 06:44:13 +08:00
|
|
|
auto Result = ExternalFS->openFileForRead(F->getExternalContentsPath());
|
|
|
|
if (!Result)
|
|
|
|
return Result;
|
2014-03-01 05:16:07 +08:00
|
|
|
|
2015-12-11 07:41:39 +08:00
|
|
|
auto ExternalStatus = (*Result)->status();
|
|
|
|
if (!ExternalStatus)
|
|
|
|
return ExternalStatus.getError();
|
2014-03-01 05:16:07 +08:00
|
|
|
|
2015-12-11 07:41:39 +08:00
|
|
|
// FIXME: Update the status with the name and VFSMapped.
|
|
|
|
Status S = getRedirectedFileStatus(Path, F->useExternalName(UseExternalNames),
|
|
|
|
*ExternalStatus);
|
|
|
|
return std::unique_ptr<File>(
|
2019-08-15 23:54:37 +08:00
|
|
|
std::make_unique<FileWithFixedStatus>(std::move(*Result), S));
|
2014-02-22 07:39:37 +08:00
|
|
|
}
|
|
|
|
|
2018-11-16 09:15:54 +08:00
|
|
|
std::error_code
|
|
|
|
RedirectingFileSystem::getRealPath(const Twine &Path,
|
|
|
|
SmallVectorImpl<char> &Output) const {
|
2019-01-16 06:36:41 +08:00
|
|
|
ErrorOr<RedirectingFileSystem::Entry *> Result = lookupPath(Path);
|
2018-11-16 09:15:54 +08:00
|
|
|
if (!Result) {
|
2019-10-16 07:08:57 +08:00
|
|
|
if (shouldUseExternalFS() &&
|
2018-11-16 09:15:54 +08:00
|
|
|
Result.getError() == llvm::errc::no_such_file_or_directory) {
|
|
|
|
return ExternalFS->getRealPath(Path, Output);
|
|
|
|
}
|
|
|
|
return Result.getError();
|
|
|
|
}
|
|
|
|
|
2019-01-16 06:36:41 +08:00
|
|
|
if (auto *F =
|
|
|
|
dyn_cast<RedirectingFileSystem::RedirectingFileEntry>(*Result)) {
|
2018-11-16 09:15:54 +08:00
|
|
|
return ExternalFS->getRealPath(F->getExternalContentsPath(), Output);
|
|
|
|
}
|
|
|
|
// Even if there is a directory entry, fall back to ExternalFS if allowed,
|
|
|
|
// because directories don't have a single external contents path.
|
2019-10-16 07:08:57 +08:00
|
|
|
return shouldUseExternalFS() ? ExternalFS->getRealPath(Path, Output)
|
|
|
|
: llvm::errc::invalid_argument;
|
2018-11-16 09:15:54 +08:00
|
|
|
}
|
|
|
|
|
2014-02-22 07:39:37 +08:00
|
|
|
IntrusiveRefCntPtr<FileSystem>
|
2014-08-18 06:12:58 +08:00
|
|
|
vfs::getVFSFromYAML(std::unique_ptr<MemoryBuffer> Buffer,
|
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
|
|
|
SourceMgr::DiagHandlerTy DiagHandler,
|
2018-10-10 21:27:25 +08:00
|
|
|
StringRef YAMLFilePath, void *DiagContext,
|
2014-02-22 07:39:37 +08:00
|
|
|
IntrusiveRefCntPtr<FileSystem> ExternalFS) {
|
2015-10-07 18:05:44 +08:00
|
|
|
return RedirectingFileSystem::create(std::move(Buffer), DiagHandler,
|
2016-06-13 04:05:23 +08:00
|
|
|
YAMLFilePath, DiagContext,
|
|
|
|
std::move(ExternalFS));
|
2014-02-22 07:39:37 +08:00
|
|
|
}
|
|
|
|
|
2019-01-16 06:36:41 +08:00
|
|
|
static void getVFSEntries(RedirectingFileSystem::Entry *SrcE,
|
|
|
|
SmallVectorImpl<StringRef> &Path,
|
2016-12-22 15:06:03 +08:00
|
|
|
SmallVectorImpl<YAMLVFSEntry> &Entries) {
|
|
|
|
auto Kind = SrcE->getKind();
|
2019-01-16 06:36:41 +08:00
|
|
|
if (Kind == RedirectingFileSystem::EK_Directory) {
|
|
|
|
auto *DE = dyn_cast<RedirectingFileSystem::RedirectingDirectoryEntry>(SrcE);
|
2016-12-22 15:06:03 +08:00
|
|
|
assert(DE && "Must be a directory");
|
2019-01-16 06:36:41 +08:00
|
|
|
for (std::unique_ptr<RedirectingFileSystem::Entry> &SubEntry :
|
2016-12-22 15:06:03 +08:00
|
|
|
llvm::make_range(DE->contents_begin(), DE->contents_end())) {
|
|
|
|
Path.push_back(SubEntry->getName());
|
|
|
|
getVFSEntries(SubEntry.get(), Path, Entries);
|
|
|
|
Path.pop_back();
|
|
|
|
}
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
2019-01-16 06:36:41 +08:00
|
|
|
assert(Kind == RedirectingFileSystem::EK_File && "Must be a EK_File");
|
|
|
|
auto *FE = dyn_cast<RedirectingFileSystem::RedirectingFileEntry>(SrcE);
|
2016-12-22 15:06:03 +08:00
|
|
|
assert(FE && "Must be a file");
|
|
|
|
SmallString<128> VPath;
|
|
|
|
for (auto &Comp : Path)
|
|
|
|
llvm::sys::path::append(VPath, Comp);
|
|
|
|
Entries.push_back(YAMLVFSEntry(VPath.c_str(), FE->getExternalContentsPath()));
|
|
|
|
}
|
|
|
|
|
|
|
|
void vfs::collectVFSFromYAML(std::unique_ptr<MemoryBuffer> Buffer,
|
|
|
|
SourceMgr::DiagHandlerTy DiagHandler,
|
|
|
|
StringRef YAMLFilePath,
|
|
|
|
SmallVectorImpl<YAMLVFSEntry> &CollectedEntries,
|
|
|
|
void *DiagContext,
|
|
|
|
IntrusiveRefCntPtr<FileSystem> ExternalFS) {
|
|
|
|
RedirectingFileSystem *VFS = RedirectingFileSystem::create(
|
|
|
|
std::move(Buffer), DiagHandler, YAMLFilePath, DiagContext,
|
|
|
|
std::move(ExternalFS));
|
2019-01-16 06:36:41 +08:00
|
|
|
ErrorOr<RedirectingFileSystem::Entry *> RootE = VFS->lookupPath("/");
|
2016-12-22 15:06:03 +08:00
|
|
|
if (!RootE)
|
|
|
|
return;
|
|
|
|
SmallVector<StringRef, 8> Components;
|
|
|
|
Components.push_back("/");
|
|
|
|
getVFSEntries(*RootE, Components, CollectedEntries);
|
|
|
|
}
|
|
|
|
|
2014-02-22 07:39:37 +08:00
|
|
|
UniqueID vfs::getNextVirtualUniqueID() {
|
2014-03-03 01:08:31 +08:00
|
|
|
static std::atomic<unsigned> UID;
|
|
|
|
unsigned ID = ++UID;
|
2014-02-22 07:39:37 +08:00
|
|
|
// The following assumes that uint64_t max will never collide with a real
|
|
|
|
// dev_t value from the OS.
|
|
|
|
return UniqueID(std::numeric_limits<uint64_t>::max(), ID);
|
|
|
|
}
|
2014-05-21 05:43:27 +08:00
|
|
|
|
|
|
|
void YAMLVFSWriter::addFileMapping(StringRef VirtualPath, StringRef RealPath) {
|
|
|
|
assert(sys::path::is_absolute(VirtualPath) && "virtual path not absolute");
|
|
|
|
assert(sys::path::is_absolute(RealPath) && "real path not absolute");
|
|
|
|
assert(!pathHasTraversal(VirtualPath) && "path traversal is not supported");
|
|
|
|
Mappings.emplace_back(VirtualPath, RealPath);
|
|
|
|
}
|
|
|
|
|
2014-05-22 06:46:51 +08:00
|
|
|
namespace {
|
2018-03-29 06:09:09 +08:00
|
|
|
|
2014-05-22 06:46:51 +08:00
|
|
|
class JSONWriter {
|
|
|
|
llvm::raw_ostream &OS;
|
|
|
|
SmallVector<StringRef, 16> DirStack;
|
2018-03-29 06:09:09 +08:00
|
|
|
|
|
|
|
unsigned getDirIndent() { return 4 * DirStack.size(); }
|
|
|
|
unsigned getFileIndent() { return 4 * (DirStack.size() + 1); }
|
2014-05-22 06:46:51 +08:00
|
|
|
bool containedIn(StringRef Parent, StringRef Path);
|
|
|
|
StringRef containedPart(StringRef Parent, StringRef Path);
|
|
|
|
void startDirectory(StringRef Path);
|
|
|
|
void endDirectory();
|
|
|
|
void writeEntry(StringRef VPath, StringRef RPath);
|
2014-05-21 05:43:27 +08:00
|
|
|
|
2014-05-22 06:46:51 +08:00
|
|
|
public:
|
|
|
|
JSONWriter(llvm::raw_ostream &OS) : OS(OS) {}
|
2018-03-29 06:09:09 +08:00
|
|
|
|
2016-04-14 03:28:21 +08:00
|
|
|
void write(ArrayRef<YAMLVFSEntry> Entries, Optional<bool> UseExternalNames,
|
|
|
|
Optional<bool> IsCaseSensitive, Optional<bool> IsOverlayRelative,
|
2018-10-25 06:40:54 +08:00
|
|
|
StringRef OverlayDir);
|
2014-05-22 06:46:51 +08:00
|
|
|
};
|
2018-03-29 06:09:09 +08:00
|
|
|
|
|
|
|
} // namespace
|
2014-05-21 05:43:27 +08:00
|
|
|
|
2014-05-22 06:46:51 +08:00
|
|
|
bool JSONWriter::containedIn(StringRef Parent, StringRef Path) {
|
2014-05-21 06:12:58 +08:00
|
|
|
using namespace llvm::sys;
|
2018-03-29 06:09:09 +08:00
|
|
|
|
2014-05-21 06:12:58 +08:00
|
|
|
// Compare each path component.
|
|
|
|
auto IParent = path::begin(Parent), EParent = path::end(Parent);
|
|
|
|
for (auto IChild = path::begin(Path), EChild = path::end(Path);
|
|
|
|
IParent != EParent && IChild != EChild; ++IParent, ++IChild) {
|
|
|
|
if (*IParent != *IChild)
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
// Have we exhausted the parent path?
|
|
|
|
return IParent == EParent;
|
2014-05-21 05:43:27 +08:00
|
|
|
}
|
|
|
|
|
2014-05-22 06:46:51 +08:00
|
|
|
StringRef JSONWriter::containedPart(StringRef Parent, StringRef Path) {
|
|
|
|
assert(!Parent.empty());
|
2014-05-21 05:43:27 +08:00
|
|
|
assert(containedIn(Parent, Path));
|
|
|
|
return Path.slice(Parent.size() + 1, StringRef::npos);
|
|
|
|
}
|
|
|
|
|
2014-05-22 06:46:51 +08:00
|
|
|
void JSONWriter::startDirectory(StringRef Path) {
|
|
|
|
StringRef Name =
|
|
|
|
DirStack.empty() ? Path : containedPart(DirStack.back(), Path);
|
|
|
|
DirStack.push_back(Path);
|
|
|
|
unsigned Indent = getDirIndent();
|
|
|
|
OS.indent(Indent) << "{\n";
|
|
|
|
OS.indent(Indent + 2) << "'type': 'directory',\n";
|
|
|
|
OS.indent(Indent + 2) << "'name': \"" << llvm::yaml::escape(Name) << "\",\n";
|
|
|
|
OS.indent(Indent + 2) << "'contents': [\n";
|
|
|
|
}
|
|
|
|
|
|
|
|
void JSONWriter::endDirectory() {
|
|
|
|
unsigned Indent = getDirIndent();
|
|
|
|
OS.indent(Indent + 2) << "]\n";
|
|
|
|
OS.indent(Indent) << "}";
|
|
|
|
|
|
|
|
DirStack.pop_back();
|
|
|
|
}
|
|
|
|
|
|
|
|
void JSONWriter::writeEntry(StringRef VPath, StringRef RPath) {
|
|
|
|
unsigned Indent = getFileIndent();
|
|
|
|
OS.indent(Indent) << "{\n";
|
|
|
|
OS.indent(Indent + 2) << "'type': 'file',\n";
|
|
|
|
OS.indent(Indent + 2) << "'name': \"" << llvm::yaml::escape(VPath) << "\",\n";
|
|
|
|
OS.indent(Indent + 2) << "'external-contents': \""
|
|
|
|
<< llvm::yaml::escape(RPath) << "\"\n";
|
|
|
|
OS.indent(Indent) << "}";
|
|
|
|
}
|
|
|
|
|
|
|
|
void JSONWriter::write(ArrayRef<YAMLVFSEntry> Entries,
|
2016-04-14 03:28:21 +08:00
|
|
|
Optional<bool> UseExternalNames,
|
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
|
|
|
Optional<bool> IsCaseSensitive,
|
|
|
|
Optional<bool> IsOverlayRelative,
|
|
|
|
StringRef OverlayDir) {
|
2014-05-22 06:46:51 +08:00
|
|
|
using namespace llvm::sys;
|
2014-05-21 05:43:27 +08:00
|
|
|
|
|
|
|
OS << "{\n"
|
|
|
|
" 'version': 0,\n";
|
2014-05-22 06:46:51 +08:00
|
|
|
if (IsCaseSensitive.hasValue())
|
|
|
|
OS << " 'case-sensitive': '"
|
|
|
|
<< (IsCaseSensitive.getValue() ? "true" : "false") << "',\n";
|
2016-04-14 03:28:21 +08:00
|
|
|
if (UseExternalNames.hasValue())
|
|
|
|
OS << " 'use-external-names': '"
|
|
|
|
<< (UseExternalNames.getValue() ? "true" : "false") << "',\n";
|
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
|
|
|
bool UseOverlayRelative = false;
|
|
|
|
if (IsOverlayRelative.hasValue()) {
|
|
|
|
UseOverlayRelative = IsOverlayRelative.getValue();
|
2018-10-10 21:27:25 +08:00
|
|
|
OS << " 'overlay-relative': '" << (UseOverlayRelative ? "true" : "false")
|
|
|
|
<< "',\n";
|
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
|
|
|
}
|
2014-05-21 05:43:27 +08:00
|
|
|
OS << " 'roots': [\n";
|
2014-05-22 06:46:51 +08:00
|
|
|
|
2014-07-15 09:24:35 +08:00
|
|
|
if (!Entries.empty()) {
|
|
|
|
const YAMLVFSEntry &Entry = Entries.front();
|
|
|
|
startDirectory(path::parent_path(Entry.VPath));
|
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
|
|
|
|
|
|
|
StringRef RPath = Entry.RPath;
|
|
|
|
if (UseOverlayRelative) {
|
|
|
|
unsigned OverlayDirLen = OverlayDir.size();
|
|
|
|
assert(RPath.substr(0, OverlayDirLen) == OverlayDir &&
|
|
|
|
"Overlay dir must be contained in RPath");
|
|
|
|
RPath = RPath.slice(OverlayDirLen, RPath.size());
|
|
|
|
}
|
|
|
|
|
|
|
|
writeEntry(path::filename(Entry.VPath), RPath);
|
2014-07-15 09:24:35 +08:00
|
|
|
|
|
|
|
for (const auto &Entry : Entries.slice(1)) {
|
|
|
|
StringRef Dir = path::parent_path(Entry.VPath);
|
|
|
|
if (Dir == DirStack.back())
|
|
|
|
OS << ",\n";
|
|
|
|
else {
|
|
|
|
while (!DirStack.empty() && !containedIn(DirStack.back(), Dir)) {
|
|
|
|
OS << "\n";
|
|
|
|
endDirectory();
|
|
|
|
}
|
|
|
|
OS << ",\n";
|
|
|
|
startDirectory(Dir);
|
2014-05-22 06:46:51 +08:00
|
|
|
}
|
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
|
|
|
StringRef RPath = Entry.RPath;
|
|
|
|
if (UseOverlayRelative) {
|
|
|
|
unsigned OverlayDirLen = OverlayDir.size();
|
|
|
|
assert(RPath.substr(0, OverlayDirLen) == OverlayDir &&
|
|
|
|
"Overlay dir must be contained in RPath");
|
|
|
|
RPath = RPath.slice(OverlayDirLen, RPath.size());
|
|
|
|
}
|
|
|
|
writeEntry(path::filename(Entry.VPath), RPath);
|
2014-05-22 06:46:51 +08:00
|
|
|
}
|
|
|
|
|
2014-07-15 09:24:35 +08:00
|
|
|
while (!DirStack.empty()) {
|
|
|
|
OS << "\n";
|
|
|
|
endDirectory();
|
|
|
|
}
|
2014-05-22 06:46:51 +08:00
|
|
|
OS << "\n";
|
|
|
|
}
|
|
|
|
|
2014-07-15 09:24:35 +08:00
|
|
|
OS << " ]\n"
|
2014-05-21 05:43:27 +08:00
|
|
|
<< "}\n";
|
|
|
|
}
|
2014-05-22 06:46:51 +08:00
|
|
|
|
|
|
|
void YAMLVFSWriter::write(llvm::raw_ostream &OS) {
|
2018-09-27 06:16:28 +08:00
|
|
|
llvm::sort(Mappings, [](const YAMLVFSEntry &LHS, const YAMLVFSEntry &RHS) {
|
2014-05-22 06:46:51 +08:00
|
|
|
return LHS.VPath < RHS.VPath;
|
|
|
|
});
|
|
|
|
|
2016-04-14 03:28:21 +08:00
|
|
|
JSONWriter(OS).write(Mappings, UseExternalNames, IsCaseSensitive,
|
2018-10-25 06:40:54 +08:00
|
|
|
IsOverlayRelative, OverlayDir);
|
2014-05-22 06:46:51 +08:00
|
|
|
}
|
2014-06-25 03:37:16 +08:00
|
|
|
|
2015-10-09 21:28:13 +08:00
|
|
|
VFSFromYamlDirIterImpl::VFSFromYamlDirIterImpl(
|
2019-01-16 06:36:41 +08:00
|
|
|
const Twine &_Path,
|
|
|
|
RedirectingFileSystem::RedirectingDirectoryEntry::iterator Begin,
|
|
|
|
RedirectingFileSystem::RedirectingDirectoryEntry::iterator End,
|
|
|
|
bool IterateExternalFS, FileSystem &ExternalFS, std::error_code &EC)
|
2018-10-27 06:14:33 +08:00
|
|
|
: Dir(_Path.str()), Current(Begin), End(End),
|
|
|
|
IterateExternalFS(IterateExternalFS), ExternalFS(ExternalFS) {
|
|
|
|
EC = incrementImpl(/*IsFirstTime=*/true);
|
2014-06-25 03:37:16 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
std::error_code VFSFromYamlDirIterImpl::increment() {
|
2018-10-27 06:14:33 +08:00
|
|
|
return incrementImpl(/*IsFirstTime=*/false);
|
|
|
|
}
|
|
|
|
|
|
|
|
std::error_code VFSFromYamlDirIterImpl::incrementExternal() {
|
|
|
|
assert(!(IsExternalFSCurrent && ExternalDirIter == directory_iterator()) &&
|
|
|
|
"incrementing past end");
|
|
|
|
std::error_code EC;
|
|
|
|
if (IsExternalFSCurrent) {
|
|
|
|
ExternalDirIter.increment(EC);
|
|
|
|
} else if (IterateExternalFS) {
|
|
|
|
ExternalDirIter = ExternalFS.dir_begin(Dir, EC);
|
|
|
|
IsExternalFSCurrent = true;
|
|
|
|
if (EC && EC != errc::no_such_file_or_directory)
|
|
|
|
return EC;
|
|
|
|
EC = {};
|
|
|
|
}
|
|
|
|
if (EC || ExternalDirIter == directory_iterator()) {
|
|
|
|
CurrentEntry = directory_entry();
|
|
|
|
} else {
|
|
|
|
CurrentEntry = *ExternalDirIter;
|
|
|
|
}
|
|
|
|
return EC;
|
2018-08-08 07:00:40 +08:00
|
|
|
}
|
|
|
|
|
2018-10-27 06:14:33 +08:00
|
|
|
std::error_code VFSFromYamlDirIterImpl::incrementContent(bool IsFirstTime) {
|
2018-10-30 05:21:55 +08:00
|
|
|
assert((IsFirstTime || Current != End) && "cannot iterate past end");
|
2018-10-27 06:14:33 +08:00
|
|
|
if (!IsFirstTime)
|
|
|
|
++Current;
|
2018-08-08 07:00:40 +08:00
|
|
|
while (Current != End) {
|
2014-06-25 03:37:16 +08:00
|
|
|
SmallString<128> PathStr(Dir);
|
|
|
|
llvm::sys::path::append(PathStr, (*Current)->getName());
|
2019-11-05 01:23:07 +08:00
|
|
|
sys::fs::file_type Type = sys::fs::file_type::type_unknown;
|
2018-09-14 20:47:38 +08:00
|
|
|
switch ((*Current)->getKind()) {
|
2019-01-16 06:36:41 +08:00
|
|
|
case RedirectingFileSystem::EK_Directory:
|
2018-10-10 21:27:25 +08:00
|
|
|
Type = sys::fs::file_type::directory_file;
|
|
|
|
break;
|
2019-01-16 06:36:41 +08:00
|
|
|
case RedirectingFileSystem::EK_File:
|
2018-10-10 21:27:25 +08:00
|
|
|
Type = sys::fs::file_type::regular_file;
|
|
|
|
break;
|
2016-08-13 02:18:24 +08:00
|
|
|
}
|
2020-01-29 03:23:46 +08:00
|
|
|
CurrentEntry = directory_entry(std::string(PathStr.str()), Type);
|
2018-10-27 06:14:33 +08:00
|
|
|
return {};
|
2016-08-12 10:17:26 +08:00
|
|
|
}
|
2018-10-27 06:14:33 +08:00
|
|
|
return incrementExternal();
|
|
|
|
}
|
2016-08-13 02:18:24 +08:00
|
|
|
|
2018-10-27 06:14:33 +08:00
|
|
|
std::error_code VFSFromYamlDirIterImpl::incrementImpl(bool IsFirstTime) {
|
|
|
|
while (true) {
|
|
|
|
std::error_code EC = IsExternalFSCurrent ? incrementExternal()
|
|
|
|
: incrementContent(IsFirstTime);
|
|
|
|
if (EC || CurrentEntry.path().empty())
|
|
|
|
return EC;
|
|
|
|
StringRef Name = llvm::sys::path::filename(CurrentEntry.path());
|
|
|
|
if (SeenNames.insert(Name).second)
|
|
|
|
return EC; // name not seen before
|
|
|
|
}
|
|
|
|
llvm_unreachable("returned above");
|
2014-06-25 03:37:16 +08:00
|
|
|
}
|
2014-06-26 04:25:40 +08:00
|
|
|
|
2018-10-10 21:27:25 +08:00
|
|
|
vfs::recursive_directory_iterator::recursive_directory_iterator(
|
|
|
|
FileSystem &FS_, const Twine &Path, std::error_code &EC)
|
2014-06-26 04:25:40 +08:00
|
|
|
: FS(&FS_) {
|
|
|
|
directory_iterator I = FS->dir_begin(Path, EC);
|
2017-03-14 08:14:40 +08:00
|
|
|
if (I != directory_iterator()) {
|
2018-11-01 07:36:10 +08:00
|
|
|
State = std::make_shared<detail::RecDirIterState>();
|
|
|
|
State->Stack.push(I);
|
2014-06-26 04:25:40 +08:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
vfs::recursive_directory_iterator &
|
|
|
|
recursive_directory_iterator::increment(std::error_code &EC) {
|
2018-11-01 07:36:10 +08:00
|
|
|
assert(FS && State && !State->Stack.empty() && "incrementing past end");
|
|
|
|
assert(!State->Stack.top()->path().empty() && "non-canonical end iterator");
|
2014-06-26 04:25:40 +08:00
|
|
|
vfs::directory_iterator End;
|
2018-11-01 07:36:10 +08:00
|
|
|
|
|
|
|
if (State->HasNoPushRequest)
|
|
|
|
State->HasNoPushRequest = false;
|
|
|
|
else {
|
|
|
|
if (State->Stack.top()->type() == sys::fs::file_type::directory_file) {
|
|
|
|
vfs::directory_iterator I = FS->dir_begin(State->Stack.top()->path(), EC);
|
|
|
|
if (I != End) {
|
|
|
|
State->Stack.push(I);
|
|
|
|
return *this;
|
|
|
|
}
|
2014-06-26 04:25:40 +08:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2018-11-01 07:36:10 +08:00
|
|
|
while (!State->Stack.empty() && State->Stack.top().increment(EC) == End)
|
|
|
|
State->Stack.pop();
|
2014-06-26 04:25:40 +08:00
|
|
|
|
2018-11-01 07:36:10 +08:00
|
|
|
if (State->Stack.empty())
|
2014-06-26 04:25:40 +08:00
|
|
|
State.reset(); // end iterator
|
|
|
|
|
|
|
|
return *this;
|
2014-07-07 01:43:24 +08:00
|
|
|
}
|