[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