#
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 ...
|