Commit Graph

36 Commits

Author SHA1 Message Date
Jan Korous 759465ee34 [YAMLVFSWriter] Fix for delimiters
Differential Revision: https://reviews.llvm.org/D79809
2020-05-12 15:43:10 -07:00
Jan Korous c0330bc00f [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
2020-05-07 10:58:43 -07:00
Jonas Devlieghere 3ef33e69de [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
2020-03-27 15:16:52 -07:00
Adrian McCarthy da45bd2321 [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
2020-02-05 11:38:20 -08:00
Benjamin Kramer adcd026838 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.
2020-01-28 23:25:25 +01:00
Adrian McCarthy 738b5c9639 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
2019-12-18 11:38:04 -08:00
Adrian McCarthy 1275ab1620 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
2019-11-14 08:48:47 -08:00
Simon Pilgrim e1000f1d67 VirtualFileSystem - fix uninitialized variable warnings. NFCI. 2019-11-04 17:24:35 +00:00
Simon Pilgrim 0caee27620 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
2019-10-16 11:17:08 +00:00
Simon Pilgrim 115a6ecdf1 RealFile - fix self-initialization warning in constructor.
llvm-svn: 374994
2019-10-16 11:16:59 +00:00
Jonas Devlieghere 21703543a7 [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
2019-10-15 23:08:57 +00:00
Jonas Devlieghere 409b4b5fb3 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
2019-10-15 18:37:00 +00:00
Jonas Devlieghere 0b9981b180 [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
2019-10-15 17:14:24 +00:00
Simon Pilgrim 7ce312307a VirtualFileSystem - replace dyn_cast<>+assert with cast<> calls. NFCI.
Silences a number of clang static analyzer null dereference warnings.

llvm-svn: 373325
2019-10-01 11:25:29 +00:00
Jonas Devlieghere 97fc8eb438 [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
2019-09-13 23:27:31 +00:00
Jonas Devlieghere 0eaee545ee [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
2019-08-15 15:54:37 +00:00
Reid Kleckner cc418a3af4 [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 00:34:13 +00:00
Simon Pilgrim cfe6fe06ab [VirtualFileSystem] Fix uninitialized variable warning. NFCI.
llvm-svn: 361371
2019-05-22 11:20:52 +00:00
Duncan P. N. Exon Smith e7b9464943 VFS: Avoid some unnecessary std::string copies
Thread Twine a little deeper through the VFS to avoid unnecessarily
constructing the same std::string twice in a parameter sequence:

    Twine -> std::string -> StringRef -> std::string

Changing a few parameters from StringRef to Twine avoids the early call
to `Twine::str()`.

llvm-svn: 354739
2019-02-23 23:48:47 +00:00
Sam McCall 15e475e222 Reapply [VFS] Allow multiple RealFileSystem instances with independent CWDs.
This reverts commit r351091.
The original mac breakages are addressed by ensuring the root directory
we're working from is fully symlink-resolved before starting.

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

llvm-svn: 354026
2019-02-14 12:57:01 +00:00
Chandler Carruth 2946cd7010 Update the file headers across all of the LLVM projects in the monorepo
to reflect the new license.

We understand that people may be surprised that we're moving the header
entirely to discuss the new license. We checked this carefully with the
Foundation's lawyer and we believe this is the correct approach.

Essentially, all code in the project is now made available by the LLVM
project under our new license, so you will see that the license headers
include that license only. Some of our contributors have contributed
code under our old license, and accordingly, we have retained a copy of
our old license notice in the top-level files in each project and
repository.

llvm-svn: 351636
2019-01-19 08:50:56 +00:00
Pavel Labath 1ad53ca2b0 [Support] Remove error return value from one overload of fs::make_absolute
Summary:
The version of make_absolute which accepted a specific directory to use
as the "base" for the computation could never fail, even though it
returned a std::error_code. The reason for that seems to be historical
-- the CWD flavour (which can fail due to failure to retrieve CWD) was
there first, and the new version was implemented by extending that.

This removes the error return value from the non-CWD overload and
reimplements the CWD version on top of that. This enables us to remove
some dead code where people were pessimistically trying to handle the
errors returned from this function.

Reviewers: zturner, sammccall

Subscribers: hiraditya, kristina, llvm-commits

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

llvm-svn: 351317
2019-01-16 09:55:32 +00:00
Jonas Devlieghere 1a0ce65ad3 [VFS] Move RedirectingFileSystem interface into header (NFC)
This moves the RedirectingFileSystem into the header so it can be
extended. This is needed in LLDB we need a way to obtain the external
path to deal with FILE* and file descriptor APIs.

Discussion on the mailing list:
http://lists.llvm.org/pipermail/llvm-dev/2018-November/127755.html

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

llvm-svn: 351265
2019-01-15 22:36:41 +00:00
Amara Emerson e07cdb107e Revert "[VFS] Allow multiple RealFileSystem instances with independent CWDs."
This reverts commit r351079, r351069 and r351050 as it broken the greendragon bots on macOS.

llvm-svn: 351091
2019-01-14 18:32:09 +00:00
Sam McCall 7a99727c62 [VFS] Fix unused variable warning. NFC
llvm-svn: 351069
2019-01-14 14:13:24 +00:00