<html><head><meta http-equiv="Content-Type" content="text/html; charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">HI Sam,<div class=""><br class=""></div><div class="">Thanks again for taking the time to discuss this. <br class=""><div><br class=""><blockquote type="cite" class=""><div class="">On Nov 15, 2018, at 3:02 AM, Sam McCall <<a href="mailto:sammccall@google.com" class="">sammccall@google.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class=""><div dir="ltr" class=""><div class="">I'd like to get some more perspectives on the role of the VirtualFileSystem abstraction in llvm/Support.</div><div class="">(The VFS layer has recently moved from Clang to LLVM, so crossposting to both lists)</div><div class=""><br class=""></div><div class=""><a href="https://reviews.llvm.org/D54277" class="">https://reviews.llvm.org/D54277</a> proposed adding a function to VirtualFileSystem to get the underlying "real file" path from a VFS path. LLDB is starting to use VFS for some filesystem interactions, but wants/needs to keep using native IO (FILE*, file descriptors) for others. There's some more context/discussion in the review.</div><div class=""><br class=""></div><div class="">My perspective is coloured by work on clang tooling, clangd etc. There we rely on VFS to ensure code (typically clang library code) works in a variety of environments, e.g:</div><div class="">in an IDE the edited file is consistently used rather than the one on disk</div><div class="">clang-tidy checks work on a local codebase, but our code review tool also runs them as a service</div><div class="">This works because all IO goes through the VFS, so VFSes are substitutable. We tend to rely on the static type system to ensure this (most people write lit tests that use the real FS).</div></div></div></div></blockquote><div><br class=""></div><div>I want to emphasize that I don't have any intention of breaking any of those or other existing use cases. I opted for the virtual file system because it provides 95% of the functionality that's needed for reproducers: the real filesystem and the redirecting file system. It has the yaml mapping writer and reader, the abstraction level above the two, etc. It feels silly to implement everything again in LLDB (actually it would be more like copy/pasting everything) just because we miss that 5%, so I'm really motivated to find a solution that works for all of us :-) </div><div><br class=""></div><blockquote type="cite" class=""><div dir="ltr" class=""><div dir="ltr" class=""><div class="">Adding facilities to use native IO together with VFS works against this, e.g. a likely interface is</div><div class=""> // Returns the OS-native path to the specified virtual file.</div><div class=""> // Returns None if Path doesn't describe a native file, or its path is unknown.</div><div class=""> Optional<string> FileSystem::getNativePath(string Path)</div><div class="">Most potential uses of such a function are going to produce code that doesn't work well with arbitrary VFSes.</div><div class="">Anecdotally, filesystems are confusing, and most features exposed by VFS end up getting misused if possible.</div></div></div></blockquote><div><br class=""></div><div>You're right and this is a problem/limitation for LLDB as well. This was the motivation for the `ExternalFileSystem` (please forgive me for the terrible name, just wanted to get the code up in phab) because it had "some" semantic meaning for both implementations. But I also understand your concerns there. </div><br class=""><blockquote type="cite" class=""><div dir="ltr" class=""><div dir="ltr" class=""><div class="">So those are my reasons for pushing back on this change, but I'm not sure how strong they are.</div><div class="">I think broadly the alternatives for LLDB are:</div><div class="">make a change like this to the VFS APIs</div><div class="">migrate to actually doing IO using VFS (likely a lot of work)</div><div class="">know which concrete VFSes they construct, and track the needed info externally</div><div class="">stop using VFS, and build separate abstractions for tracking remapping of native files etc</div><div class="">abandon the new features that depend on this file remapping</div></div></div></blockquote><div><br class=""></div><div>Can you elaborate on what you have in mind for (3) and how it differs from (4)?</div><br class=""><blockquote type="cite" class=""><div dir="ltr" class=""><div dir="ltr" class=""><div class="">As a purist, 2 and 4 seem like the cleanest options, but that's easy to say when it's someone else's work.</div></div></div></blockquote><blockquote type="cite" class=""><div dir="ltr" class=""><div dir="ltr" class=""><div class="">What path should we take here?</div></div></div></blockquote><div><br class=""></div><div>I'll withhold from answering this as I'm one of the stakeholders ;-) </div><br class=""><blockquote type="cite" class=""><div dir="ltr" class=""><div dir="ltr" class=""><div class=""><br class=""></div><div class="">Cheers, Sam</div></div></div>
</blockquote></div><br class=""></div></body></html>