forked from OSchip/llvm-project
16c7829784
Having nested macros in the C code could cause clangd to fail an assert in clang::Preprocessor::setLoadedMacroDirective() and crash. #1 0x00000000007ace30 PrintStackTraceSignalHandler(void*) /qdelacru/llvm-project/llvm/lib/Support/Unix/Signals.inc:632:1 #2 0x00000000007aaded llvm::sys::RunSignalHandlers() /qdelacru/llvm-project/llvm/lib/Support/Signals.cpp:76:20 #3 0x00000000007ac7c1 SignalHandler(int) /qdelacru/llvm-project/llvm/lib/Support/Unix/Signals.inc:407:1 #4 0x00007f096604db20 __restore_rt (/lib64/libpthread.so.0+0x12b20) #5 0x00007f0964b307ff raise (/lib64/libc.so.6+0x377ff) #6 0x00007f0964b1ac35 abort (/lib64/libc.so.6+0x21c35) #7 0x00007f0964b1ab09 _nl_load_domain.cold.0 (/lib64/libc.so.6+0x21b09) #8 0x00007f0964b28de6 (/lib64/libc.so.6+0x2fde6) #9 0x0000000001004d1a clang::Preprocessor::setLoadedMacroDirective(clang::IdentifierInfo*, clang::MacroDirective*, clang::MacroDirective*) /qdelacru/llvm-project/clang/lib/Lex/PPMacroExpansion.cpp:116:5 An example of the code that causes the assert failure: ``` ... ``` During code completion in clangd, the macros will be loaded in loadMainFilePreambleMacros() by iterating over the macro names and calling PreambleIdentifiers->get(). Since these macro names are store in a StringSet (has StringMap underlying container), the order of the iterator is not guaranteed to be same as the order seen in the source code. When clangd is trying to resolve nested macros it sometimes attempts to load them out of order which causes a macro to be stored twice. In the example above, ECHO2 macro gets resolved first, but since it uses another macro that has not been resolved it will try to resolve/store that as well. Now there are two MacroDirectives stored in the Preprocessor, ECHO and ECHO2. When clangd tries to load the next macro, ECHO, the preprocessor fails an assert in clang::Preprocessor::setLoadedMacroDirective() because there is already a MacroDirective stored for that macro name. In this diff, I check if the macro is already inside the IdentifierTable and if it is skip it so that it is not resolved twice. Reviewed By: kadircet Differential Revision: https://reviews.llvm.org/D101870 |
||
|---|---|---|
| .. | ||
| clang-apply-replacements | ||
| clang-change-namespace | ||
| clang-doc | ||
| clang-include-fixer | ||
| clang-move | ||
| clang-query | ||
| clang-reorder-fields | ||
| clang-tidy | ||
| clangd | ||
| docs | ||
| modularize | ||
| pp-trace | ||
| test | ||
| tool-template | ||
| unittests | ||
| .gitignore | ||
| CMakeLists.txt | ||
| CODE_OWNERS.TXT | ||
| LICENSE.TXT | ||
| README.txt | ||
README.txt
//===----------------------------------------------------------------------===// // Clang Tools repository //===----------------------------------------------------------------------===// Welcome to the repository of extra Clang Tools. This repository holds tools that are developed as part of the LLVM compiler infrastructure project and the Clang frontend. These tools are kept in a separate "extra" repository to allow lighter weight checkouts of the core Clang codebase. This repository is only intended to be checked out inside of a full LLVM+Clang tree, and in the 'tools/extra' subdirectory of the Clang checkout. All discussion regarding Clang, Clang-based tools, and code in this repository should be held using the standard Clang mailing lists: http://lists.llvm.org/mailman/listinfo/cfe-dev Code review for this tree should take place on the standard Clang patch and commit lists: http://lists.llvm.org/mailman/listinfo/cfe-commits If you find a bug in these tools, please file it in the LLVM bug tracker: http://llvm.org/bugs/