[clang-tidy] problem with relative paths in compile_commands.json

clang-tidy seems to have problems with relative paths in command lines
in compile_commands.json.

Consider the following case:

$ cat > test.cpp
int main(int argc, char* argv[]) {
    return 0;
$ cat > compile_commands.json
  "directory": "/home/kljohann/test/build",
  "command": "/usr/bin/clang++ -Wunused-parameter -o test.cpp.o -c ../test.cpp",
  "file": "/home/kljohann/test/test.cpp"
$ mkdir build
$ clang-tidy test.cpp
2 warnings generated.
clang-tidy: ../tools/clang/lib/Basic/SourceManager.cpp:422: const
clang::SourceManager::getOrCreateContentCache(const clang::FileEntry*,
bool): Assertion `FileEnt && "Didn't specify a file entry to use?"'
[1] 23129 abort clang-tidy test.cpp

My guess is the following: In ClangTool::run we chdir() into the
"directory" that is specified in compile_commands.json. Then, the
relative file name is stored in ClangTidyMessage (I checked that this
is the case using gdb). Eventually handleErrors() is called, but by
then we already chdired back and thus in ErrorReporter::getLocation
  const FileEntry *File = SourceMgr.getFileManager().getFile(FilePath);
is a null pointer (checked using gdb).
On the other hand this is my first venture into the clang source code,
so I may very well be wrong. I hope you can reproduce this bug.

All the best,

+Sam who’s been doing a fair bit with clang-tidy recently (Sam, feel free to add Manuel, Daniel, whomever else might be more appropriate if you prefer)

+Alexander Kornienko

This looks like http://llvm.org/PR22385, and it looks like we need to store absolute path in ClangTidyError and tooling:Replacement (or maybe both relative and absolute path, as I suspect that we need the former too).