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

[Ben Langmuir]

On Feb 7, 2014, at 11:31 AM, Manuel Klimek <klimek at google.com> wrote:
> 
> I'd like to consider it design-wise at least on a straw-man level (to be shot down ;)
> 
> If we want to support this in the future, it might affect both the ownership and the API design question. For example, one design straw-man would be to have interfaces for FileSystem, Directory and File, where FileSystem can give you Directory's and those again can give you Files. That would trivially support using directory-entry based OS interfaces where they are available, but would mean more code overhead per FileSystem implementation.
> 
> A different approach would be to use descriptors for files and directories, and have only a single FileSystem interface that can handle the instances. Seems slightly less "nice" from a user point of view, but potentially simpler and less overhead for the implementation.
> 
> From the other mails in this thread it sounds to me more like you want to basically punt on those questions and just provide the interface and access methods to get buffers for files. That might also be fine for now, but I'd prefer if it is a conscious decision rather than an accidental one :)

What filesystem modifications would you consider to be ‘unrelated’ in a compilation?  E.g. what if clang is invoked from the ‘real location’ src-head, but there are command-line options that refer to absolute paths in ‘src’.  Would we try to recover?  I think I would need a concrete idea of what the desired model of consistency is before I could be convinced this is a solvable problem.

Now, specifically about the straw-man proposal: one of the things I like about reusing the llvm::sys::fs interface is that it makes the change very small for users.  Both of these options seem to require giving that up for a handle-based API where clients need to think about a new object(s) for any file operations they want to use.

I wonder if handling the clang-invocation-location issue can be solved by virtually mapping `pwd` to `pwd -P` right at the beginning of the compilation?  That would allow path-based operations to still work.  However, that probably doesn’t scale if you want to treat *every* path that the compiler looks up this way, since you would explode the number of mappings…  So it really depends on what our model of consistency is.

Ben

> 
> Cheers,
> /Manuel