[PATCH] D17104: [VFS] Drop path traversal assertion

[Bruno Cardoso Lopes via cfe-commits]

bruno added a comment.

> Your two-path solution seems like it's on the right track but I don't like that it brings us back to having ".." in the source path.


Given the two-path solution, another thing we could do in the first path, is to default to the remove_dots() version for the source, i.e. "/install-dir/lib/clang/3.8.0/include" instead of "/install-dir/bin/../lib/clang/3.8.0/include". The path after remove_dots() might be different from what realpath() would return (but this is covered in the 2nd path) but at least we canonicalize for a future virtual path request (which can safely request the VFS based on the returned path from remove_dots()). What do you think about it?

> Do you think it's feasible to store a mapping from the realpath, and additionally have a symlink entry in the VFS (which would be a new feature for the VFS in general)?

>  When we write the YAML file, we could realpath(source) and if it is different from remove_dots(source) we would add a symlink entry.


Correct me if I'm wrong, but do you suggest we have a new entry type in the YAML file for declaring symlinks? Right now, we handle symlinks by copying them out as real files inside the VFS. However, adding extra "name" entries to map for real paths for such symlinks inside the YAML should do it.

> I suspect figuring out whthe symlink would add non-trivial overhead, since we'd have to look at every path component... at least it would only be paid when creating the YAML, not when reading it. Any thoughts?


I agree that the price should only be paid only when creating the YAML files.


http://reviews.llvm.org/D17104