The test is added in Testcase is at https://reviews.llvm.org/D52775. I tried to add the test to clang's code
completion test, it doesn't reproduce the crash.
Details
Diff Detail
- Repository
- rC Clang
- Build Status
Buildable 23348 Build 23347: arc lint + arc unit
Event Timeline
For reference, the crash stack is like:
ClangdTests: ../include/llvm/ADT/StringSet.h:39: std::pair<typename base::iterator, bool> llvm::StringSet<llvm::MallocAllocator>::insert(llvm::StringRef) [AllocatorTy = llvm::MallocAllocator]: Assertion `!Key.empty()' failed. #0 0x000000000061e5ff llvm::sys::PrintStackTrace(llvm::raw_ostream&) /llvm-upstream/build/../lib/Support/Unix/Signals.inc:490:13 #1 0x000000000061c942 llvm::sys::RunSignalHandlers() llvm-upstream/build/../lib/Support/Signals.cpp:68:18 #2 0x000000000061e942 SignalHandler(int) llvm-upstream/build/../lib/Support/Unix/Signals.inc:353:1 #3 0x00007f1c964fb0c0 __restore_rt (/lib/x86_64-linux-gnu/libpthread.so.0+0x110c0) #4 0x00007f1c9508cfcf gsignal (/lib/x86_64-linux-gnu/libc.so.6+0x32fcf) #5 0x00007f1c9508e3fa abort (/lib/x86_64-linux-gnu/libc.so.6+0x343fa) #6 0x00007f1c95085e37 (/lib/x86_64-linux-gnu/libc.so.6+0x2be37) #7 0x00007f1c95085ee2 (/lib/x86_64-linux-gnu/libc.so.6+0x2bee2) #8 0x0000000000a19f75 (llvm-upstream/build/tools/clang/tools/extra/unittests/clangd/./ClangdTests+0xa19f75) #9 0x0000000000a1b72d (anonymous namespace)::DepCollectorPPCallbacks::InclusionDirective(clang::SourceLocation, clang::Token const&, llvm::StringRef, bool, clang::CharSourceRange, clang::FileEntry const*, llvm::StringRef, llvm::StringRef, clang::Module const*, clang::SrcMgr::CharacteristicKind) llvm-upstream/build/../tools/clang/lib/Frontend/DependencyFile.cpp:0:20 #10 0x0000000000ab958c clang::PPChainedCallbacks::InclusionDirective(clang::SourceLocation, clang::Token const&, llvm::StringRef, bool, clang::CharSourceRange, clang::FileEntry const*, llvm::StringRef, llvm::StringRef, clang::Module const*, clang::SrcMgr::CharacteristicKind) llvm-upstream/build/../tools/clang/include/clang/Lex/PPCallbacks.h:389:3 #11 0x0000000000ab958c clang::PPChainedCallbacks::InclusionDirective(clang::SourceLocation, clang::Token const&, llvm::StringRef, bool, clang::CharSourceRange, clang::FileEntry const*, llvm::StringRef, llvm::StringRef, clang::Module const*, clang::SrcMgr::CharacteristicKind) llvm-upstream/build/../tools/clang/include/clang/Lex/PPCallbacks.h:389:3 #12 0x0000000000abf696 clang::Preprocessor::HandleIncludeDirective(clang::SourceLocation, clang::Token&, clang::DirectoryLookup const*, clang::FileEntry const*, bool) llvm-upstream/build/../tools/clang/lib/Lex/PPDirectives.cpp:2043:16 #13 0x0000000000ac2589 clang::Preprocessor::HandleDirective(clang::Token&) llvm-upstream/build/../tools/clang/lib/Lex/PPDirectives.cpp:1021:14 #14 0x0000000000a97ac9 clang::Lexer::LexTokenInternal(clang::Token&, bool) llvm-upstream/build/../tools/clang/lib/Lex/Lexer.cpp:3934:7 #15 0x0000000000a957ad clang::Lexer::Lex(clang::Token&) llvm-upstream/build/../tools/clang/lib/Lex/Lexer.cpp:3155:3 #16 0x0000000000af4954 clang::Preprocessor::Lex(clang::Token&) llvm-upstream/build/../tools/clang/lib/Lex/Preprocessor.cpp:895:12 #17 0x00000000012da277 clang::Parser::ConsumeToken() llvm-upstream/build/../tools/clang/include/clang/Parse/Parser.h:416:12 #18 0x00000000012dc8d9 clang::Parser::Initialize() llvm-upstream/build/../tools/clang/lib/Parse/Parser.cpp:520:1
Could you add a regression test please? Also could you run this through a debugger and get a backtrace from a debugger instead of the crash report, it seems to be missing a few things likely from optimizations which a debugger will usually pick up. This seems to be asserting due to a duplicate element in a set.
Thank you.
Thanks for the comment. The assertion is caused by inserting an empty Filename to StringSet. The typo correction code change the Filename (which will be used afterwards) even the typo correction heuristic fails (e.g. for #include "./^", Filename is changed to empty, which is unexpected). The testcase is added at https://reviews.llvm.org/D52775. Unfortunately, I couldn't reproduce it with a simple clang CodeCompletion test.
As discussed offline with @sammccall, it would be better to let the author of typo correction to fix its issues (as the typo correction code is submitted recently, and maybe buggy). The original patch fixes two issues, I rescoped the patch to make it clearer for review.