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 >
msg2.patch
Description: Binary data
_______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
