This patch modifies how we open File instances in LLDB. Rather than passing a path or FileSpec to the constructor, we now go through the virtual file system. This is needed in order to make things work with the VFS.
The current implementation doesn't use the VFS yet. The reason is that in LLDB we mostly use FILE pointers or file descriptors to manipulate files. This is currently not supported by the VFS and I haven't decided to address this yet. The two alternative I see are:
- Having the VFS translate paths. This will only work for virtual file systems where the files actually reside on disk. This would be sufficient for the reproducer use case but lacks generality.
- Having the VFS provide FILE pointers. Still we wouldn't be able to completely support in-memory vfses. I believe on POSIX there's a way to have a file point to memory, but I don't think you can do that for a file descriptor. Also not sure if that would work on Windows?
Both options are incomplete and I don't have the bandwidth to change how LLDB deals with files. I'm currently leaning towards the first alternative because LLVM doesn't provide FILE* APIs and I don't think we should start adding them now. Also I don't want to extend the VFS for just LLDB as that's going to be a pain to hook up and maintain. Anyway, I'm open to suggestions!
File::eOpenOptionRead should be sufficient, no?