<div dir="ltr"><div>This sounds like something that could break after multiple translation units support was fixed in r221600. Your analysis is sound, but I couldn't easily reproduce this issue on LLVM. Can you provide an example of a compilation database where this happens (or just the relevant part of it)?</div><div><br></div>Also, the solution you propose will not work with a virtual file system which may be the case when clang-tidy is used as a library. We need a way to recover correct path while keeping the file names exactly as they came from the SourceManager. Maybe store some additional information with clang-tidy error messages or something.<div><br></div><div>But first, I'd like to be able to reproduce this.<br><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Nov 13, 2014 at 8:26 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:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><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=""><div class="h5"><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:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style: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>
</div></div><br>_______________________________________________<br>
cfe-commits mailing list<br>
<a href="mailto:cfe-commits@cs.uiuc.edu">cfe-commits@cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits</a><br></blockquote></div>
</div></div></div>