[cfe-dev] [clang-tidy] problem with relative paths in compile_commands.json

[Alexander Kornienko]

This looks like http://llvm.org/PR22385, and it looks like we need to store
absolute path in ClangTidyError and tooling:Replacement (or maybe both
relative and absolute path, as I suspect that we need the former too).

On Fri, Feb 20, 2015 at 11:31 AM, Manuel Klimek <klimek at google.com> wrote:

> +Alexander Kornienko <alexfh at google.com>
>
> On Fri Feb 20 2015 at 12:18:49 AM David Blaikie <dblaikie at gmail.com>
> wrote:
>
>> +Sam who's been doing a fair bit with clang-tidy recently (Sam, feel free
>> to add Manuel, Daniel, whomever else might be more appropriate if you
>> prefer)
>>
>> On Thu, Feb 19, 2015 at 2:57 PM, Johann Klähn <kljohann at gmail.com> wrote:
>>
>>> clang-tidy seems to have problems with relative paths in command lines
>>> in compile_commands.json.
>>>
>>> Consider the following case:
>>>
>>> $ cat > test.cpp
>>> int main(int argc, char* argv[]) {
>>>     return 0;
>>> }
>>> $ cat > compile_commands.json
>>> [
>>> {
>>>   "directory": "/home/kljohann/test/build",
>>>   "command": "/usr/bin/clang++ -Wunused-parameter -o test.cpp.o -c
>>> ../test.cpp",
>>>   "file": "/home/kljohann/test/test.cpp"
>>> }
>>> ]
>>> $ mkdir build
>>> $ clang-tidy test.cpp
>>> 2 warnings generated.
>>> clang-tidy: ../tools/clang/lib/Basic/SourceManager.cpp:422: const
>>> clang::SrcMgr::ContentCache*
>>> clang::SourceManager::getOrCreateContentCache(const clang::FileEntry*,
>>> bool): Assertion `FileEnt && "Didn't specify a file entry to use?"'
>>> failed.
>>> [1]    23129 abort      clang-tidy test.cpp
>>>
>>> My guess is the following: In ClangTool::run we chdir() into the
>>> "directory" that is specified in compile_commands.json. Then, the
>>> relative file name is stored in ClangTidyMessage (I checked that this
>>> is the case using gdb). Eventually handleErrors() is called, but by
>>> then we already chdired back and thus in ErrorReporter::getLocation
>>>   const FileEntry *File = SourceMgr.getFileManager().getFile(FilePath);
>>> is a null pointer (checked using gdb).
>>> On the other hand this is my first venture into the clang source code,
>>> so I may very well be wrong. I hope you can reproduce this bug.
>>>
>>
>> Yeah, I can reproduce this. I know little about clang-tidy and what the
>> expected behavior is here - certainly crashing isn't ideal, but even beyond
>> that I'm not sure if the assumption is taht all the paths in the compile
>> commands database will be absolute, or relative to some specific place, etc.
>>
>> The CMake compilation database support seems to create databases with all
>> absolute paths so I imagine this doesn't come up there.
>>
>>
>> - David
>>
>>
>>>
>>> All the best,
>>> Johann
>>> _______________________________________________
>>> cfe-dev mailing list
>>> cfe-dev at cs.uiuc.edu
>>> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
>>>
>> _______________________________________________
>> cfe-dev mailing list
>> cfe-dev at cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20150223/837e0460/attachment.html>