ilya-biryukov added a comment. In https://reviews.llvm.org/D37474#861206, @cameron314 wrote:
> I suppose we could do the overlay manually in all the tests that need it; I > guess it depends on what the goal of the VFS support is. To my mind, it > doesn't make sense that a file is placed in the RealFS in the first place if > a VFS is used, but this is quite entrenched in the current design and > difficult to change. In which case, I would argue that parsing a file with a > preamble and a VFS should not give a cryptic error without an explicit > overlay, but rather "just work". But I agree my current patch is a little > crude in that it allows access to the entire RealFS via the VFS. > > I could change the automatic overlay to *only* support access to the > generated PCH file, similar to how the `FilteredFileSystem` you've pointed > out works, but for a single file only. Would that be acceptable? I totally agree, the current behavior is definitely confusing for clients using `vfs::FileSystem` without proper filesystem access on top of `ASTUnit`. Having an overlay that provides **only** the PCH file sounds like a good middle ground. Maybe we could even read the PCH contents using file APIs instead of `vfs::FileSystem` and add them into `PreprocessorOption::RemappedFileBuffers`? Do you think that would also work? Since `ASTUnit` is responsible writes PCHs to disk, it also makes sense for it to read them from disk, but accesses to all other files would go through `vfs::FileSystem`. https://reviews.llvm.org/D37474 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
