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

Rafael EspĂ­ndola rafael.espindola at gmail.com
Thu Feb 13 05:14:18 PST 2014


> 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(...);
* Remove getBufferForFile. It can just be implemented with
getBufferForOpenFile, no?
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?

I would still be uncomfortable declaring Status abi stable, but this
is a fine small set of apis to have.

Cheers,
Rafael



More information about the cfe-dev mailing list