[cfe-dev] RFC: A virtual file system for clang

[Ben Langmuir]

On Feb 13, 2014, at 5:14 AM, Rafael Espíndola <rafael.espindola at gmail.com> wrote:

>> There seem to be 2 interfaces here: one user interface, and one for
>> subclassing.
>> 
>> Are you fine with the interface for subclassing being the current
>> Status-based proposal?
> 
> The set of virtual functions currently is
> 
> virtual llvm::error_code status(const llvm::Twine &Path, Status &Result) = 0;
> virtual llvm::error_code openFileForRead(const llvm::Twine &Path,
>                                           FileDescriptor &ResultFD) = 0;
> virtual llvm::error_code getBufferForFile(
>      const llvm::Twine &Name, llvm::OwningPtr<llvm::MemoryBuffer> &Result,
>      int64_t FileSize = -1, bool RequiresNullTerminator = true) = 0;
> virtual llvm::error_code statusOfOpenFile(FileDescriptor FD, Status &Result);
> virtual llvm::error_code
>  getBufferForOpenFile(FileDescriptor FD, const llvm::Twine &Name,
>                       llvm::OwningPtr<llvm::MemoryBuffer> &Result,
>                       int64_t FileSize = -1,
>                       bool RequiresNullTerminator = true);
> 
> I would probably
> * Use ErrorOr, so ErroOr<Status> statusOfOpenFile(…);

Okay.

> * Remove getBufferForFile. It can just be implemented with
> getBufferForOpenFile, no?

By remove, do you mean make it non-virtual?  If so, I’m fine with that.  I don’t want to remove it, since the path-based getBuffer functions are commonly used.

> btw, getBufferForOpenFile is a case where returning error_code is
> probably the best we can do right now. ErrorOR<OwningPtr<..> >
> effectively requires move semantics.
> * Can status be implemented with openFileForRead + statusOfOpenFile?
> 

Status has to work on directories and other things we cannot open.  You can go the other way and just have path-based APIs, but the FIleManager uses open-file operations because it should be faster to open and then stat on a file descriptor than it is to stat a path and then open that path.  I think we really want to keep both versions.

> I would still be uncomfortable declaring Status abi stable, but this
> is a fine small set of apis to have.
> 
> Cheers,
> Rafael
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev