History log of /llvm-project/llvm/lib/Support/VirtualFileSystem.cpp (Results 76 – 100 of 120)
Revision (<<< Hide revision tags) (Show revision tags >>>) Date Author Comments
# 49556b87 30-Jan-2021 Yang Fan <nullptr.cpp@gmail.com>

[NFC][VFS] Fix a build warning due to an extra semicolon


# 719f7784 16-Jan-2021 Nathan Hawes <nhawes@apple.com>

[VFS] Combine VFSFromYamlDirIterImpl and OverlayFSDirIterImpl into a single implementation (NFC)

As a fixme notes, both of these directory iterator implementations are
conceptually similar and dupli

[VFS] Combine VFSFromYamlDirIterImpl and OverlayFSDirIterImpl into a single implementation (NFC)

As a fixme notes, both of these directory iterator implementations are
conceptually similar and duplicate the functionality of returning and uniquing
entries across two or more directories. This patch combines them into a single
class 'CombiningDirIterImpl'.

This also drops the 'Redirecting' prefix from RedirectingDirEntry and
RedirectingFileEntry to save horizontal space. There's no loss of clarity as
they already have to be prefixed with 'RedirectingFileSystem::' whenever
they're referenced anyway.

rdar://problem/72485443
Differential Revision: https://reviews.llvm.org/D94857

show more ...


# 0be9ca7c 22-Jan-2021 Jonas Devlieghere <jonas@devlieghere.com>

[VFS] Fix inconsistencies between relative paths and fallthrough.

This patch addresses inconsistencies in the way fallthrough is handled
in the RedirectingFileSystem. Rather than trying to change th

[VFS] Fix inconsistencies between relative paths and fallthrough.

This patch addresses inconsistencies in the way fallthrough is handled
in the RedirectingFileSystem. Rather than trying to change the working
directory of the external filesystem, the RedirectingFileSystem will
canonicalize every path before handing it down. This guarantees that
relative paths are resolved relative to the RedirectingFileSystem's
working directory.

This allows us to have a strictly virtual working directory, and still
fallthrough for absolute paths, but not for relative paths that would
get resolved incorrectly at the lower layer (for example, in case of the
RealFileSystem, because the strictly virtual path does not exist).

Differential revision: https://reviews.llvm.org/D95188

show more ...


Revision tags: llvmorg-11.1.0-rc1, llvmorg-11.0.1, llvmorg-11.0.1-rc2, llvmorg-11.0.1-rc1
# 75cd8d75 12-Nov-2020 Duncan P. N. Exon Smith <dexonsmith@apple.com>

Support: Add RedirectingFileSystem::create from simple list of redirections

Add an overload of `RedirectingFileSystem::create` that builds a
redirecting filesystem off of a simple vector of string p

Support: Add RedirectingFileSystem::create from simple list of redirections

Add an overload of `RedirectingFileSystem::create` that builds a
redirecting filesystem off of a simple vector of string pairs. This is
intended to be used to support `clang::arcmt::FileRemapper` and
`clang::PreprocessorOptions::RemappedFiles`.

Differential Revision: https://reviews.llvm.org/D91317

show more ...


# a22eda54 08-Dec-2020 Duncan P. N. Exon Smith <dexonsmith@apple.com>

VFS: Return new file systems as uniquely owned when possible, almost NFC

Uniformly return uniquely-owned filesystems from VFS creation APIs. The
one exception is `getRealFileSystem`, which has a sin

VFS: Return new file systems as uniquely owned when possible, almost NFC

Uniformly return uniquely-owned filesystems from VFS creation APIs. The
one exception is `getRealFileSystem`, which has a single instance and
needs to be shared.

This is almost NFC, except that it fixes a memory leak in
`vfs::collectVFSFromYAML()`.

Depends on https://reviews.llvm.org/D92888

Differential Revision: https://reviews.llvm.org/D92890

show more ...


# e763e032 05-Nov-2020 Duncan P. N. Exon Smith <dexonsmith@apple.com>

Support: Change InMemoryFileSystem::addFileNoOwn to take a MemoryBufferRef, NFC

Found this by chance when looking at the InMemoryFileSystem API, seems
like an easy cleanup.

Differential Revision: h

Support: Change InMemoryFileSystem::addFileNoOwn to take a MemoryBufferRef, NFC

Found this by chance when looking at the InMemoryFileSystem API, seems
like an easy cleanup.

Differential Revision: https://reviews.llvm.org/D90893

show more ...


Revision tags: llvmorg-11.0.0, llvmorg-11.0.0-rc6, llvmorg-11.0.0-rc5, llvmorg-11.0.0-rc4, llvmorg-11.0.0-rc3
# 37469061 31-Aug-2020 Jonas Devlieghere <jonas@devlieghere.com>

[lldb] Add reproducer verifier

Add a reproducer verifier that catches:

- Missing or invalid home directory
- Missing or invalid working directory
- Missing or invalid module/symbol paths
- Miss

[lldb] Add reproducer verifier

Add a reproducer verifier that catches:

- Missing or invalid home directory
- Missing or invalid working directory
- Missing or invalid module/symbol paths
- Missing files from the VFS

The verifier is enabled by default during replay, but can be skipped by
passing --reproducer-no-verify.

Differential revision: https://reviews.llvm.org/D86497

show more ...


# 7c80f2da 01-Sep-2020 Raphael Isemann <teemperor@gmail.com>

Revert "[lldb] Add reproducer verifier"

This reverts commit 297f69afac58fc9dc13897857a5e70131c5adc85. It broke
the Fedora 33 x86-64 bot. See the review for more info.


# 297f69af 31-Aug-2020 Jonas Devlieghere <jonas@devlieghere.com>

[lldb] Add reproducer verifier

Add a reproducer verifier that catches:

- Missing or invalid home directory
- Missing or invalid working directory
- Missing or invalid module/symbol paths
- Miss

[lldb] Add reproducer verifier

Add a reproducer verifier that catches:

- Missing or invalid home directory
- Missing or invalid working directory
- Missing or invalid module/symbol paths
- Missing files from the VFS

The verifier is enabled by default during replay, but can be skipped by
passing --reproducer-no-verify.

Differential revision: https://reviews.llvm.org/D86497

show more ...


Revision tags: llvmorg-11.0.0-rc2, llvmorg-11.0.0-rc1, llvmorg-12-init, llvmorg-10.0.1, llvmorg-10.0.1-rc4, llvmorg-10.0.1-rc3, llvmorg-10.0.1-rc2, llvmorg-10.0.1-rc1
# 759465ee 12-May-2020 Jan Korous <jkorous@apple.com>

[YAMLVFSWriter] Fix for delimiters

Differential Revision: https://reviews.llvm.org/D79809


# c0330bc0 06-May-2020 Jan Korous <jkorous@apple.com>

[YAMLVFSWriter] Fix directory handling

For empty directories (except the first one) we've been adding a file
with the same name as the directory to the result VFS mapping.

Differential Revision: ht

[YAMLVFSWriter] Fix directory handling

For empty directories (except the first one) we've been adding a file
with the same name as the directory to the result VFS mapping.

Differential Revision: https://reviews.llvm.org/D79551

show more ...


# 3ef33e69 27-Mar-2020 Jonas Devlieghere <jonas@devlieghere.com>

[VirtualFileSystem] Support directory entries in the YAMLVFSWriter

The current implementation of the JSONWriter does not support writing
out directory entries. Earlier today I added a unit test to i

[VirtualFileSystem] Support directory entries in the YAMLVFSWriter

The current implementation of the JSONWriter does not support writing
out directory entries. Earlier today I added a unit test to illustrate
the problem. When an entry is added to the YAMLVFSWriter and the path is
a directory, it will incorrectly emit the directory as a file, and any
files inside that directory will not be found by the VFS.

It's possible to partially work around the issue by only adding "leaf
nodes" (files) to the YAMLVFSWriter. However, this doesn't work for
representing empty directories. This is a problem for clients of the VFS
that want to iterate over a directory. The directory not being there is
not the same as the directory being empty.

This is not just a hypothetical problem. The FileCollector for example
does not differentiate between file and directory paths. I temporarily
worked around the issue for LLDB by ignoring directories, but I suspect
this will prove problematic sooner rather than later.

This patch fixes the issue by extending the JSONWriter to support
writing out directory entries. We store whether an entry should be
emitted as a file or directory.

Differential revision: https://reviews.llvm.org/D76670

show more ...


Revision tags: llvmorg-10.0.0, llvmorg-10.0.0-rc6, llvmorg-10.0.0-rc5, llvmorg-10.0.0-rc4, llvmorg-10.0.0-rc3, llvmorg-10.0.0-rc2, llvmorg-10.0.0-rc1
# da45bd23 22-Jan-2020 Adrian McCarthy <amccarth@google.com>

[VFS] More consistent support for Windows

Removed some #ifdefs specific to Windows handling of VFS paths. This
eliminates most of the differences between the Windows and non-Windows
code paths.

Ma

[VFS] More consistent support for Windows

Removed some #ifdefs specific to Windows handling of VFS paths. This
eliminates most of the differences between the Windows and non-Windows
code paths.

Making this work required some changes to account for the fact that VFS
file paths can be Posix style or Windows style, so you cannot just assume
that they use the host's native path style. In one case, this means
implementing our own version of make_absolute, since the filesystem code
in Support doesn't have styles in the sense that the path code does.

Differential Review: https://reviews.llvm.org/D71092

show more ...


# adcd0268 28-Jan-2020 Benjamin Kramer <benny.kra@googlemail.com>

Make llvm::StringRef to std::string conversions explicit.

This is how it should've been and brings it more in line with
std::string_view. There should be no functional change here.

This is mostly m

Make llvm::StringRef to std::string conversions explicit.

This is how it should've been and brings it more in line with
std::string_view. There should be no functional change here.

This is mostly mechanical from a custom clang-tidy check, with a lot of
manual fixups. It uncovers a lot of minor inefficiencies.

This doesn't actually modify StringRef yet, I'll do that in a follow-up.

show more ...


Revision tags: llvmorg-11-init, llvmorg-9.0.1, llvmorg-9.0.1-rc3, llvmorg-9.0.1-rc2
# 738b5c96 25-Nov-2019 Adrian McCarthy <amccarth@google.com>

Fix more VFS tests on Windows

Since VFS paths can be in either Posix or Windows style, we have to use
a more flexible definition of "absolute" path.

The key here is that FileSystem::makeAbsolute is

Fix more VFS tests on Windows

Since VFS paths can be in either Posix or Windows style, we have to use
a more flexible definition of "absolute" path.

The key here is that FileSystem::makeAbsolute is now virtual, and the
RedirectingFileSystem override checks for either concept of absolute
before trying to make the path absolute by combining it with the current
directory.

Differential Revision: https://reviews.llvm.org/D70701

show more ...


Revision tags: llvmorg-9.0.1-rc1
# 1275ab16 07-Nov-2019 Adrian McCarthy <amccarth@google.com>

Improve VFS compatibility on Windows

Keys in a virtual file system can be in Posix or Windows form or even
a combination of the two. Many VFS tests (and a few Clang tests) were
XFAILed on Windows b

Improve VFS compatibility on Windows

Keys in a virtual file system can be in Posix or Windows form or even
a combination of the two. Many VFS tests (and a few Clang tests) were
XFAILed on Windows because of false negatives when comparing paths.

First, we default CaseSenstive to false on Windows. This allows
drive letters like "D:" to match "d:". Windows filesystems are, by
default, case insensitive, so this makes sense even beyond the drive
letter.

Second, we allow slashes to match backslashes when they're used as the
root component of a path.

Both of these changes are limited to RedirectingFileSystems, so there's
little chance of affecting other path handling.

These changes allow eleven of the VFS tests to pass on Windows as well
as three other Clang tests, so they have re-enabled.

This solves the majority of PR43272. Additional VFS test failures will
be fixed in separate patches.

Differential Revision: https://reviews.llvm.org/D69958

show more ...


# e1000f1d 04-Nov-2019 Simon Pilgrim <llvm-dev@redking.me.uk>

VirtualFileSystem - fix uninitialized variable warnings. NFCI.


# 0caee276 16-Oct-2019 Simon Pilgrim <llvm-dev@redking.me.uk>

RedirectingFileSystem::openFileForRead - replace bitwise & with boolean && to fix warning

Seems to be just a typo - now matches other instances which do something similar

llvm-svn: 374995


# 115a6ecd 16-Oct-2019 Simon Pilgrim <llvm-dev@redking.me.uk>

RealFile - fix self-initialization warning in constructor.

llvm-svn: 374994


# 21703543 15-Oct-2019 Jonas Devlieghere <jonas@devlieghere.com>

[Reland][VirtualFileSystem] Support virtual working directory in the RedirectingFS

Before this patch, changing the working directory of the RedirectingFS
would just forward to its external file syst

[Reland][VirtualFileSystem] Support virtual working directory in the RedirectingFS

Before this patch, changing the working directory of the RedirectingFS
would just forward to its external file system. This prevented us from
having a working directory that only existed in the VFS mapping.

This patch adds support for a virtual working directory in the
RedirectingFileSystem. It now keeps track of its own WD in addition to
updating the WD of the external file system. This ensures that we can
still fall through for relative paths.

This change was originally motivated by the reproducer infrastructure in
LLDB where we want to deal transparently with relative paths.

Differential revision: https://reviews.llvm.org/D65677

llvm-svn: 374955

show more ...


# 409b4b5f 15-Oct-2019 Jonas Devlieghere <jonas@devlieghere.com>

Revert "[VirtualFileSystem] Support virtual working directory in the RedirectingFS"

This reverts the original commit and the follow up:

Revert "[VirtualFileSystem] Support virtual working director

Revert "[VirtualFileSystem] Support virtual working directory in the RedirectingFS"

This reverts the original commit and the follow up:

Revert "[VirtualFileSystem] Support virtual working directory in the RedirectingFS"
Revert "[test] Update YAML mapping in VirtualFileSystemTest"

llvm-svn: 374935

show more ...


# 0b9981b1 15-Oct-2019 Jonas Devlieghere <jonas@devlieghere.com>

[VirtualFileSystem] Support virtual working directory in the RedirectingFS

Before this patch, changing the working directory of the RedirectingFS
would just forward to its external file system. Thi

[VirtualFileSystem] Support virtual working directory in the RedirectingFS

Before this patch, changing the working directory of the RedirectingFS
would just forward to its external file system. This prevented us from
having a working directory that only existed in the VFS mapping.

This patch adds support for a virtual working directory in the
RedirectingFileSystem. It now keeps track of its own WD in addition to
updating the WD of the external file system. This ensures that we can
still fall through for relative paths.

This change was originally motivated by the reproducer infrastructure in
LLDB where we want to deal transparently with relative paths.

Differential revision: https://reviews.llvm.org/D65677

llvm-svn: 374917

show more ...


# 7ce31230 01-Oct-2019 Simon Pilgrim <llvm-dev@redking.me.uk>

VirtualFileSystem - replace dyn_cast<>+assert with cast<> calls. NFCI.

Silences a number of clang static analyzer null dereference warnings.

llvm-svn: 373325


Revision tags: llvmorg-9.0.0, llvmorg-9.0.0-rc6
# 97fc8eb4 13-Sep-2019 Jonas Devlieghere <jonas@devlieghere.com>

[Reproducer] Add reproducer dump command.

This adds a reproducer dump commands which makes it possible to inspect
a reproducer from inside LLDB. Currently it supports the Files, Commands
and Version

[Reproducer] Add reproducer dump command.

This adds a reproducer dump commands which makes it possible to inspect
a reproducer from inside LLDB. Currently it supports the Files, Commands
and Version providers. I'm planning to add support for the GDB Remote
provider in a follow-up patch.

Differential revision: https://reviews.llvm.org/D67474

llvm-svn: 371909

show more ...


Revision tags: llvmorg-9.0.0-rc5, llvmorg-9.0.0-rc4, llvmorg-9.0.0-rc3
# 0eaee545 15-Aug-2019 Jonas Devlieghere <jonas@devlieghere.com>

[llvm] Migrate llvm::make_unique to std::make_unique

Now that we've moved to C++14, we no longer need the llvm::make_unique
implementation from STLExtras.h. This patch is a mechanical replacement
of

[llvm] Migrate llvm::make_unique to std::make_unique

Now that we've moved to C++14, we no longer need the llvm::make_unique
implementation from STLExtras.h. This patch is a mechanical replacement
of (hopefully) all the llvm::make_unique instances across the monorepo.

llvm-svn: 369013

show more ...


12345