Clang tidy crashes on a cpp-file which only contains `#include <map>` (reduced from larger code) Replacing the code by the preprocessed code makes this crash go away. Command: clang-tidy -checks=* -extra-arg="-D__clang_tidy__" "t.cpp" Clang-tidy has been build on revision 265835, system is an Ubuntu 14.04 64bit
More information is needed. 0. Stack trace, please. Better if you run the assertions-enabled clang-tidy 1. Please figure out which check does that. 2. How does your compilation database (compile_commands.json, I guess) look like? Can you reproduce the issue using fixed compilation database (clang-tidy file.cpp -- <compile arguments>)? 3. Does this happen without the -extra-arg="-D__clang_tidy__"?
Created attachment 16204 [details] Reproduction info + stracktrace
0. See attachment 1. I've tried, though as I use -check=*,-dontwant1,-dontwant2..., it's not that easy, though it should at least be in the commits of the last few weeks (2 or 3), as I try keeping up with the trunk. 2. I'll add it too in attachment 3. Yes it does, the -extra-arg is only to workaround other clang-tidy bugs.
(In reply to comment #3) > 0. See attachment > 1 [details]. I've tried, though as I use -check=*,-dontwant1,-dontwant2..., > it's not that easy, though it should at least be in the commits of the last > few weeks (2 or 3), as I try keeping up with the trunk. > 2. I'll add it too in attachment > 3 [details]. Yes it does, the -extra-arg is only to workaround other > clang-tidy bugs. Thanks, I was able to reproduce this: $ cat /tmp/q.cc #include <map> $ clang-tidy -checks=-*,misc-misplaced-widening-cast /tmp/q.cc -- -std=c++11 PC: @ 0x7fad758a5720 (unknown) clang::ast_type_traits::ASTNodeKind::getFromNode() @ 0x7fad75e052d7 928 FailureSignalHandler() @ 0x7fad738193d0 1504 __restore_rt @ 0x7fad74f5c083 32 clang::ast_matchers::internal::DynTypedMatcher::matchesNoKindCheck() ... The problem is in the recently added hasReturnValue matcher: AST_MATCHER_P(ReturnStmt, hasReturnValue, internal::Matcher<Expr>, InnerMatcher) { return InnerMatcher.matches(*Node.getRetValue(), Finder, Builder); } It dereferences Node.getRetValue() which can be null. The fix should be committed soon: http://reviews.llvm.org/D18991
The mentioned fix is committed in http://reviews.llvm.org/rL266043