<div dir="ltr"><div>The contract of the VFS was a tree of "directories" containing "files" that you can access via providing a "path" and getting a "char buffer" with content. Noone ever said that any of these "files" have any sort of semblance on the "real drives". That's what ~~clang~~ llvm::fs::getRealFS() was about, giving you a VFS that bridged back to the real deal.</div><div><br></div><div>If some client code puts effort into properly mounting up Clang's standard library files into memory or their own VFS impl --- or only allows usage of code that does *NOT* use the standard library *AT ALL* --- then the frontend can go through without every touching, or even seeing, the realFS at all.<br></div><br></div><br><div class="gmail_quote"><div dir="ltr">Sam McCall <<a href="mailto:sammccall@google.com">sammccall@google.com</a>> ezt írta (időpont: 2018. nov. 27., K, 19:52):<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><div dir="ltr">On Tue, Nov 27, 2018 at 7:01 PM Jonas Devlieghere <<a href="mailto:jdevlieghere@apple.com" target="_blank">jdevlieghere@apple.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word;line-break:after-white-space">Hi Sam,<div><br></div><div><div>Does extending the status with a path sound reasonable? This would work similar to the current Name field, which is controlled by UseExternalName. </div><div><br></div><div>Please let me know what you think.</div><div><br></div><div>Thanks,</div><div>Jonas </div></div></div></blockquote><div><br></div><div>Design-wise, adding a second Name field to Status doesn't seem significantly different than adding a "getOtherName" field to VFS.</div><div>I don't think it's really reasonable to have this in the VFS interfaces, because using it in any way means you're coupled to particular implementations.</div><div><br></div><div>Implementation-wise, it seems the only way to do that would be to add an extra string to Status, and some applications probably keep a lot of Status objects. So it doesn't seem like an improvement vs the VFS method.</div><div><br></div><div>Overall I think if LLDB wants to wants to break abstraction and use the native filesystem sometimes, it should have concrete private implementations with wider interfaces, and bridge to common code by having them implement the VFS interfaces. The contract of VFS may have been "real filesystem with some redirected files", but I don't think it has been for several years, and people rely on this.</div><div><br></div><div>I'm not an owner here though. I don't really know how these decisions get made, and would like to hear more opinions.</div></div></div>
</blockquote></div>