<div dir="ltr">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.</div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Nov 12, 2014 at 5:40 PM, Aaron Wishnick <span dir="ltr"><<a href="mailto:aaron.s.wishnick@gmail.com" target="_blank">aaron.s.wishnick@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">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.<div><br></div><div>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.</div><div><br></div><div>My fix is for ClangTidyMessage to store an absolute FilePath in its constructor. I've attached the patch.</div><div><br></div><div>Thanks,</div><div>Aaron</div></div>
</blockquote></div><br></div>