Revert "[YAMLVFSWriter][Test][NFC] Add couple tests"

This reverts commit 7143d7925490e9123b1c93305700221584ba10c6.
Breaks check-llvm on Windows, see e.g.
http://lab.llvm.org:8011/builders/clang-x64-

Revert "[YAMLVFSWriter][Test][NFC] Add couple tests"

This reverts commit 7143d7925490e9123b1c93305700221584ba10c6.
Breaks check-llvm on Windows, see e.g.
http://lab.llvm.org:8011/builders/clang-x64-windows-msvc/builds/15919/steps/stage%201%20check/logs/stdio

show more ...

[YAMLVFSWriter][Test][NFC] Add couple tests

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

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

[YAMLVFSWriter][Tests] Fix YAMLVFSWriterTest

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

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

[VirtualFileSystem] Add unit test for vfs::YAMLVFSWriter

Add a unit test for vfs::YAMLVFSWriter.

This patch exposes an issue in the writer: when we call addFileMapping
with a directory, the VFS wri

[VirtualFileSystem] Add unit test for vfs::YAMLVFSWriter

Add a unit test for vfs::YAMLVFSWriter.

This patch exposes an issue in the writer: when we call addFileMapping
with a directory, the VFS writer will emit it as a regular file, causing
any of the nested files or directories to not be found.

show more ...

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

[llvm] Replace SmallStr.str().str() with std::string conversion operator.

Use the std::string conversion operator introduced in
d7049213d0fcda691c9e79f9b41e357198d99738.

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

[VFS] Disable check for ../foo on Windows

I'm not sure how .. is resolved on Windows. Disable it for now to make
the bots happy again.

[VFS] Extend virtual working directory test

Extend the virtual working directory test with a few edge cases that are
not currently tested.

Fix an unused variable introduced in rL374955 / rG21703543.

Even though this is a unit test, it still may be run under optimization.

llvm-svn: 374961

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

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

[test] Update YAML mapping in VirtualFileSystemTest

The 'bar' directory should be part of the root rather than the file
itself.

llvm-svn: 374930

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

[VFS] Add reverse iterator to OverlayFileSystem

Add a reverse iterator to the overlay file system. This makes it
possible to take overlays from one OverlayFileSystem, and add them to
another.

Diffe

[VFS] Add reverse iterator to OverlayFileSystem

Add a reverse iterator to the overlay file system. This makes it
possible to take overlays from one OverlayFileSystem, and add them to
another.

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

llvm-svn: 364986

show more ...

[X86] Use PC-relative mode for the kernel code model

Summary:
The Linux kernel uses PC-relative mode, so allow that when the code model is
"kernel".

Reviewers: craig.topper

Reviewed By: craig.topp

[X86] Use PC-relative mode for the kernel code model

Summary:
The Linux kernel uses PC-relative mode, so allow that when the code model is
"kernel".

Reviewers: craig.topper

Reviewed By: craig.topper

Subscribers: llvm-commits, kees, nickdesaulniers

Tags: #llvm

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

llvm-svn: 358343

show more ...

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 i

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

show more ...

[VFS] Fix warning and use better check.

llvm-svn: 352527

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 ne

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

show more ...

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

[VFS] Disable unix-assuming VFS test on windows

llvm-svn: 351079

[VFS] Allow multiple RealFileSystem instances with independent CWDs.

Summary:
Previously only one RealFileSystem instance was available, and its working
directory is shared with the process. This do

[VFS] Allow multiple RealFileSystem instances with independent CWDs.

Summary:
Previously only one RealFileSystem instance was available, and its working
directory is shared with the process. This doesn't work well for multithreaded
programs that want to work with relative paths - the vfs::FileSystem is assumed
to provide the working directory, but a thread cannot control this exclusively.

The new vfs::createPhysicalFileSystem() factory copies the process's working
directory initially, and then allows it to be independently modified.

This implementation records the working directory path, and glues it to relative
paths to provide the correct absolute path to the sys::fs:: functions.
This will give different results in unusual situations (e.g. the CWD is moved).

The main alternative is the use of openat(), fstatat(), etc to ask the OS to
resolve paths relative to a directory handle which can be kept open. This is
more robust. There are two reasons not to do this initially:
1. these functions are not available on all supported Unixes, and are somewhere
between difficult and unavailable on Windows. So we need a path-based
fallback anyway.
2. this would mean also adding support at the llvm::sys::fs level, which is a
larger project. My clearest idea is an OS-specific `BaseDirectory` object
that can be optionally passed to functions there. Eventually this could be
backed by either paths or a fd where openat() is supported.
This is a large project, and demonstrating here that a path-based fallback
works is a useful prerequisite.

There is some subtlety to the path-manipulation mechanism:
- when setting the working directory, both Specified=makeAbsolute(path) and
Resolved=realpath(path) are recorded. These may differ in the presence of
symlinks.
- getCurrentWorkingDirectory() and makeAbsolute() use Specified - this is
similar to the behavior of $PWD and sys::path::current_path
- IO operations like openFileForRead use Resolved. This is similar to the
behavior of an openat() based implementation, that doesn't see changes
in symlinks.
There may still be combinations of operations and FS states that yield unhelpful
behavior. This is hard to avoid with symlinks and FS abstractions :(

The caching behavior of the current working directory is removed in this patch.
getRealFileSystem() is now specified to link to the process CWD, so the caching
is incorrect.
The user who needed this so far is clangd, which will immediately switch to
createPhysicalFileSystem().

Reviewers: ilya-biryukov, bkramer, labath

Subscribers: ioeric, kadircet, kristina, llvm-commits

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

llvm-svn: 351050

show more ...

[VFS] Add isLocal to ProxyFileSystem and add unit tests.

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

llvm-svn: 349410