[PATCH] [clang-tidy] Fix ClangTidyMessage for files included with relative paths

[Aaron Wishnick]

I have an updated patch for this; I found one issue when a diagnostic is
emitted where the SourceManager doesn't have a corresponding filename.

On Wed, Nov 12, 2014 at 5:40 PM, Aaron Wishnick <aaron.s.wishnick at gmail.com>
wrote:

> I found a bug when running clang-tidy with a compilation database that
> specified its include paths as a relative path. The bug occurred when a
> diagnostic was emitted with a note in a file it included, where the file's
> include path was specified in the compilation database as a relative path
> (i.e. "-I../include"). When the ClangTidyMessage is first created in
> emitDiagnosticMessage, it asks the SourceManager for the filename
> corresponding to the location, and stores only that.
>
> The bug is that this could be a relative path. Later on, when it goes to
> render the diagnostic, the FileManager can't find the file by its relative
> path, causing an assertion in SourceManager.cpp, line 428: "Didn't specify
> a file entry to use?". This happens because ClangTool::run() changes to the
> directory specified in the compilation database by calling chdir(), and
> then restores the previous working directory. When the ClangTidyMessage is
> created, the working directory is the one specified in the compilation
> database, so the relative path works, but when it's rendered later on, the
> working directory has been restored to clang-tidy's initial working
> directory.
>
> My fix is for ClangTidyMessage to store an absolute FilePath in its
> constructor. I've attached the patch.
>
> Thanks,
> Aaron
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20141113/92f48589/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: msg2.patch
Type: application/octet-stream
Size: 925 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20141113/92f48589/attachment.obj>