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

[Rafael Avila de Espindola]

Sent from my iPhone

> On Feb 12, 2014, at 19:51, Ben Langmuir <blangmuir at apple.com> wrote:
> 
> 
> On Feb 12, 2014, at 2:26 PM, Rafael Espíndola <rafael.espindola at gmail.com> wrote:
> 
>>>> Please also use the opportunity to modernize the API when possible (using ErrorOr for example).
>>> 
>>> I think keeping the interface as close to llvm::sys::fs as possible is really helpful for staging this in.  It makes it easier to see the correspondence between the real file system and the virtual one, and it makes updating clients easier.  If the intention is to modernize llvm::sys::fs as well, then I feel that’s orthogonal to what I want to accomplish.  Is the existing interface actually a pain point? It seems pretty easy to use to me.
>> 
>> Well, it means more code to change when we do fix llvm:sys::fs :-(
>> 
>> The main issue with returning error_code is that it is really easy to
>> ignore the error (like with plain posix functions). With ErrorOr we
>> get an assert if someone tries to use a result in an error condition.
>> 
>> Cheers,
>> Rafael
> 
> 
> What would you do with the predicate functions?  Most (all?) are overloaded like so:
> 
> error_code predicate(const Twine &Path, bool &Result);
> // overload for clients that don’t differentiate between negative results and errors
> bool predicate(const Twine &Path) {
>  bool Result;
>  return !predicate(Path, Result) && Result;
> }
> 
> This prevents creating ErrorOr<bool> predicate(const Twine& Path), which results in ambiguity.
> 

It probably depends on the predicate. The fist thing to check is if both versions are needed. If there is really use for both, we would need different names or make predicates an exception to the rule.

I don't remember the API well enough to have an opinion right now. I can take a look when I get home.

Let's leave the predicates as is for now then.

Btw, how do you guys plan to expose this via libclang? Have it pass a mapping or actually allow it to provide function pointers?

> Ben

Cheers,
Rafael