ilya-biryukov added a comment. In https://reviews.llvm.org/D37474#862187, @cameron314 wrote:
> I'll change the overlay to only allow access to the PCH. > > I agree that it would be nice to only read the PCH using real filesystem APIs > in order to be symmetrical, but this seems non-trivial. It also feels like a > step in the wrong direction -- ideally the VFS would hold the PCH too instead > of putting it on disk, in my opinion. Unfortunately `vfs::FileSystem` is a read-only API, and AFAIK this is by design. So we should not hope that would ever happen. > I'm not sure adding a remapped file buffer would work, since it's unclear to > me exactly at which point the PCH is written relative to the multiple places > it's read. Additionally, there's code that does directory traversal in the > current VFS to find a PCH when given a directory name instead of a file name; > this only works if the VFS is aware of the PCH, or if the code is rewritten > to use the underlying file system. Fair point, the directory traversal code would only work with vfs. We can use assumptions about our input, though. `ASTUnit` controls PCH creation and AFAIK it in our case pch will always point to a file. Moreover, the path seems to PCH seems to always be absolute, so we should not care about working directory of vfs either. Using remapped buffers would make the code simpler, would not require custom vfs implementations and you're also right that it would look more symmetrical since we'll use filesystem API for both writes and reads of PCH. Maybe we could try this approach? https://reviews.llvm.org/D37474 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits