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

[Manuel Klimek]

On Thu, Feb 13, 2014 at 2:14 PM, 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(...);
> * 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?


In this case, +1 for those ideas...


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


> Cheers,
> Rafael
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20140213/605bb2d8/attachment.html>