<div dir="ltr">Thanks for taking a look. Here are steps to reproduce the issue. In short, it's important that clang-tidy is run in a separate working directory from the source code. In the stack trace, the issue is that the SourceManager can't find the header. In ErrorReporter::getLocation(), FilePath is "../header.h", and the working directory is "/Users/awishnick/clang-tidy/build_debug".<div><br></div><div><div><font face="monospace">awishnick-mac:build_debug awishnick$ cat /Users/awishnick/clang-tidy-bug/header.h </font></div><div><font face="monospace">void f(int n) {</font></div><div><font face="monospace"> int *p = 0;</font></div><div><font face="monospace"> *p = n;</font></div><div><font face="monospace">}</font></div><div><font face="monospace">awishnick-mac:build_debug awishnick$ cat /Users/awishnick/clang-tidy-bug/src/source.c </font></div><div><font face="monospace">#include "header.h"</font></div><div><font face="monospace">int main() { f(4); }</font></div><div><font face="monospace">awishnick-mac:build_debug awishnick$ cat /Users/awishnick/clang-tidy-bug/src/compile_commands.json </font></div><div><font face="monospace">[</font></div><div><font face="monospace">{</font></div><div><font face="monospace"> "directory": "/Users/awishnick/clang-tidy-bug/src",</font></div><div><font face="monospace"> "command": "clang -I../ source.c",</font></div><div><font face="monospace"> "file": "/Users/awishnick/clang-tidy-bug/src/source.c"</font></div><div><font face="monospace">}</font></div><div><font face="monospace">]</font></div><div><font face="monospace">awishnick-mac:build_debug awishnick$ bin/clang-tidy -p /Users/awishnick/clang-tidy-bug/src/compile_commands.json /Users/awishnick/clang-tidy-bug/src/source.c </font></div><div><font face="monospace">Assertion failed: (FileEnt && "Didn't specify a file entry to use?"), function getOrCreateContentCache, file /Users/awishnick/clang-tidy/llvm/tools/clang/lib/Basic/SourceManager.cpp, line 428.</font></div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Nov 14, 2014 at 7:47 AM, Alexander Kornienko <span dir="ltr"><<a href="mailto:alexfh@google.com" target="_blank">alexfh@google.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"><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"><div><div class="h5">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></div></div><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><div class="h5"><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><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: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></div></div>_______________________________________________<br>
cfe-commits mailing list<br>
<a href="mailto:cfe-commits@cs.uiuc.edu" target="_blank">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>
</blockquote></div><br></div>