This is an archive of the discontinued LLVM Phabricator instance.

[PProcesssor] Filename should fall back to the written name when typo correction fails.
ClosedPublic

Authored by hokein on Oct 2 2018, 3:01 AM.

Diff Detail

Repository
rC Clang

Event Timeline

hokein created this revision.Oct 2 2018, 3:01 AM
hokein added a comment.Oct 2 2018, 3:02 AM

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
kristina added a reviewer: kristina.EditedOct 2 2018, 3:14 AM
kristina added a subscriber: kristina.

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.

hokein updated this revision to Diff 167935.Oct 2 2018, 6:26 AM

Rescope the patch.

hokein retitled this revision from [Preprocessor] Fix an assertion failure trigged in clangd #include completion. to [PProcesssor] Filename should fall back to the written name when typo correction fails. .Oct 2 2018, 6:26 AM
hokein edited the summary of this revision. (Show Details)

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.

sammccall accepted this revision.Oct 2 2018, 6:42 AM
This revision is now accepted and ready to land.Oct 2 2018, 6:42 AM
hokein updated this revision to Diff 167942.Oct 2 2018, 7:04 AM
hokein retitled this revision from [PProcesssor] Filename should fall back to the written name when typo correction fails. to [PProcesssor] Filename should fall back to the written name when typo correction fails..

Rebase.

This revision was automatically updated to reflect the committed changes.