[PATCH] D54277: Extend VFS with function to get external path.

[Sam McCall via Phabricator via llvm-commits]

sammccall added a comment.

In https://reviews.llvm.org/D54277#1297570, @JDevlieghere wrote:

> In https://reviews.llvm.org/D54277#1296661, @sammccall wrote:
>
> > In https://reviews.llvm.org/D54277#1296400, @JDevlieghere wrote:
> >
> > > In https://reviews.llvm.org/D54277#1296175, @sammccall wrote:
> > >
> > > > I don't understand the concept of an "external path". What is it in the general case, when would you want to pass a path through this function vs using it directly?
> > > >
> > > > From the patch description, it sounds like it may be specific to LLDB and/or RedirectingFileSystem. If so, maybe it shouldn't be on the interface?
> > >
> > >
> > > It's true that this is only relevant for VFS implementations that are somehow backed by disk. I'm curious what you have in mind. How would it not be on the interface and still work transparently?
> >
> >
> > I can't really answer these questions without knowing what an external path is or when you'd want to use it.
> >  Could you describe it here or add some documentation to the patch?
>
>
> I'll try here first and we can always improve the patch later.
>
> One notable difference between llvm/clang and LLDB is how the latter deals with files. In addition to using memory buffers, LLDB manipulates the majority of files through file pointers (`FILE*`) and file descriptors. It's also a lot less explicit in whether it's opening a file for reading or writing. By this I mean in llvm we have functions like `openMemoryBufferForWriting` or `openMemoryBufferForReading` while in LLDB we would just pass a different open flag. While I would love to change how LLDB manipulates files, I simply don't have the bandwidth to do that right now. So that brings me to my current problem: how do I access files from LLDB through the VFS.


So if I understand correctly, you want a way to devirtualize the VFS: to take a VFS file and get a concrete `FILE*` out of it. (In this case, via the filename and `fopen()`).

The fact that VFS doesn't have any way to do this is an important property, it's what makes the file system virtual.
VFS allows code to work in the same way on OS-native, in-memory, or distributed filesystems, and `getExternalPath` would break that - any code that called it can only work when the files are 1:1 with native OS files. Code that wants to couple to the FS implementation in this way shouldn't work transparently with VFS, because it breaks the design goal that VFSes are substitutable.

For what you're trying to do, I'd suggest one of the following:

- use a concrete VFS implementation that maps files and exposes the functions you need (e.g. expose RedirectingFileSystem from VFS.h with an appropriate public interface)
- use the existing `getRealPath` if you know which concrete VFSes you're using and it happens to do what you want
- track the correspondence between virtual and real paths externally (where you set up the FS)
- decouple LLDB's IO from the concrete filesystem (use VFS file instead of FILE*)


https://reviews.llvm.org/D54277