benlangmuir added a comment. > Now, we try to use the new YAML file + cache from a new clang invocation. > When the FileManager requests status in (2) for the path > "/install-dir/bin/../lib/clang/3.8.0/include/altivec.h" neither > "remove_dots()" nor "realpath()" would be able to resolve it to > "/private/tmp/a/b/lib/clang/3.8.0/include/altivec.h" and will fallback to > search the real filesystem instead, if this is a different machine, it will > fail. Since we are looking at a virtual path in (2) it could makes sense to > use remove_dots() but it won't make sense to use "realpath()".
> > How do you propose we fix that? Ugh, I forgot about this case. Sorry for making this sound simpler than it is! 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. 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. 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? http://reviews.llvm.org/D17104 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
