[PATCH] [clang-tidy] Fix ClangTidyMessage for files included with relative paths

Aaron Wishnick aaron.s.wishnick at gmail.com
Wed Nov 12 14:40:44 PST 2014


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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20141112/f09d99f0/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: message-abs-path.patch
Type: application/octet-stream
Size: 882 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20141112/f09d99f0/attachment.obj>


More information about the cfe-commits mailing list