Context

I work on the Fuchsia team, which has an open source kythe integration for cxx currently. I'm attempting to upgrade our kythe version in our infra from 0.0.53 (ancient!) to 0.0.71 so I can use the new Rust extractor which I landed recently.

Previous behavior

Back in 0.0.53, there was no (or very little) path normalization for required_input.info.path. So if clang reported a path as ../../foo.cc, it would get entered that way in required_input[].info.path.

This worked out because the directory we run the cxx_extractor from is our build directory (which makes sense, because that's where our build commands expect to run, and all paths are relative to our build directory).

The Fuchsia (and Chromium) tree is organized like:

   <root>/
  /       \ 
src/   out/

Most source files are in the src directory and the build happens in theout directory. This means that the path to source files from the build directory is ../src/path/to/foo.cc.

New behavior

It seems that now, the PathCleaner requires that each path shares a common prefix with the CWD of the cxx_extractor, which for us is the build directory. If it doesn't, it falls back to an absolute path as the value for required_input.info.path.

We end up triggering this condition because our root in PathCleaner is /out and our path is /src/path/to/foo. The path doesn't have the root directory as a prefix, and so it shows up in the FileInfo as an absolute path.

The issue

It seems that FileInfo paths are used as the VFS paths for the indexer.

So using the new version of Kythe, the VFS contains paths for required_input files at absolute paths (/src/foo.cc), while the compiler commands are looking for them at relative paths (../src/foo.cc, ).

Options

1. Obviously, the way I posted here basically restores the behavior of 0.0.53 (output relative paths to make the VFS paths in the indexer match the paths the compiler wants to look for). It seems this might have broader implications, and I don't want to land this if I'm going to break other clients.
2. Add some option which tells PathCleaner not to fall back to absolute paths
3. Something else I haven't thought of

Originally posted by @wittrock in #6180 (comment)