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)?
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. But first, I'd like to be able to reproduce this. On Thu, Nov 13, 2014 at 8:26 PM, Aaron Wishnick <[email protected]> wrote: > 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 < > [email protected]> 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 >> > > > _______________________________________________ > cfe-commits mailing list > [email protected] > http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits >
_______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
