For now, this is only used by its unit tests. It is similar to the API
in llvm::sys::fs::recursive_directory_iterator, but without some of the
more complex features like requesting that the iterator not recurse into
the next directory, for example.
llvm-svn: 211732
The API is based on sys::fs::directory_iterator, but it allows iterating
over overlays and the yaml-based VFS. For now, it isn't used by
anything (except its tests).
llvm-svn: 211623
If we lookup a path using its 'real' path first, we need to ensure that
when we run header search we still use the VFS-mapped path or we will
not be able to find the corresponding module for the header.
The real problem is that we tie the name of a file to its underlying
FileEntry, which is uniqued by inode, so we only ever get the first name
it is looked up by. This doesn't work with modules, which rely on a
specific file system structure. I'm hoping to have time to write up a
proposal for fixing this more permanently soon, but as a stopgap this
patch updates the name of the file's directory if it comes from a VFS
mapping.
llvm-svn: 209534
There are a couple of issues with writing VFS maps that are awkward to
fix within the current mutually recursive approach. Instead, replace
the algorithm with an iterative version that uses an explicit stack of
directories.
Includes tests for cases the old approach was tripping on.
llvm-svn: 209332
Checking if a path starts with another path isn't sufficient for
determining if one is contained within the heirarchy of the other.
We need to ensure that the substring ends at a directory boundary.
llvm-svn: 209250
This moves the logic to write a JSON VFS mapping from the C api into
VirtualFileSystem, so that we can use it internally.
No functional change.
llvm-svn: 209241
Use llvm::sys::fs::make_absolute to get an absolute path before
matching. Also, allow "." directories to enable testing. ".." is still
not supported, and will require crossing file system boundaries to
implement correctly.
llvm-svn: 202903