llvmbot
commented
11 months ago @llvm/issue-subscribers-clang-frontend
Author: Bernhard Rosenkraenzer (berolinux)
Clang (not clang++) crashes on a file that contains just "::", throwing an assertion that such code should be guarded by checking for C++.
Of course this is not valid C, but I'd expect clang to give a proper error instead of an assertion and a backtrace.
```
$ echo '::' >test.c
$ clang test.c
clang-17: /builddir/build/BUILD/llvm-project-17.0.5.src/clang/lib/Parse/Parser.cpp:2180: bool clang::Parser::TryAnnotateCXXScopeToken(bool): Assertion `getLangOpts().CPlusPlus && "Call sites of this function should be guarded by checking for C++"' failed.
PLEASE submit a bug report to https://github.com/llvm/llvm-project/issues/ and include the crash backtrace, preprocessed source, and associated run script.
Stack dump:
0. Program arguments: /usr/bin/clang-17 -cc1 -triple x86_64-pc-linux-gnu -emit-obj -mrelax-all -dumpdir a- -disable-free -clear-ast-before-backend -main-file-name output-pstoedit-18c507.c -mrelocation-model pic -pic-level 2 -pic-is-pie -mframe-pointer=all -fmath-errno -ffp-contract=on -fno-rounding-math -mconstructor-aliases -funwind-tables=2 -target-cpu x86-64 -tune-cpu generic -debugger-tuning=gdb -fcoverage-compilation-dir=/tmp -resource-dir /usr/lib64/clang/17 -internal-isystem /usr/lib64/clang/17/include -internal-isystem /usr/local/include -internal-isystem /usr/bin/../lib64/gcc/x86_64-openmandriva-linux-gnu/13.1.1/../../../../x86_64-openmandriva-linux-gnu/include -internal-externc-isystem /include -internal-externc-isystem /usr/include -fdebug-compilation-dir=/tmp -ferror-limit 19 -fgnuc-version=13.1.1 -fcolor-diagnostics -faddrsig -D__GCC_HAVE_DWARF2_CFI_ASM=1 -o /tmp/test.o -x c test.c
1. output-pstoedit-18c507.c:1:1: current parser token '::'
#0 0x00007f514409b796 llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) (/lib64/libLLVM-17.so+0x489b796)
#1 0x00007f514409a40a llvm::sys::RunSignalHandlers() (/lib64/libLLVM-17.so+0x489a40a)
#2 0x00007f514409b0b4 (/lib64/libLLVM-17.so+0x489b0b4)
#3 0x00007f513f2556f0 (/lib64/libc.so.6+0x3d6f0)
#4 0x00007f513f2a49bc (/lib64/libc.so.6+0x8c9bc)
#5 0x00007f513f255642 gsignal (/lib64/libc.so.6+0x3d642)
#6 0x00007f513f23e4ad abort (/lib64/libc.so.6+0x264ad)
#7 0x00007f513f23e3d5 (/lib64/libc.so.6+0x263d5)
#8 0x00007f513f24e042 (/lib64/libc.so.6+0x36042)
#9 0x00007f514a95d8a2 clang::Parser::TryAnnotateCXXScopeToken(bool) (/lib64/libclang-cpp.so.17+0x175d8a2)
#10 0x00007f514a880d4b clang::Parser::ParseDeclarationSpecifiers(clang::DeclSpec&, clang::Parser::ParsedTemplateInfo const&, clang::AccessSpecifier, clang::Parser::DeclSpecContext, clang::Parser::LateParsedAttrList*, clang::ImplicitTypenameContext) (/lib64/libclang-cpp.so.17+0x1680d4b)
#11 0x00007f514a9569ed clang::Parser::ParseDeclOrFunctionDefInternal(clang::ParsedAttributes&, clang::ParsedAttributes&, clang::ParsingDeclSpec&, clang::AccessSpecifier) (/lib64/libclang-cpp.so.17+0x17569ed)
#12 0x00007f514a956874 clang::Parser::ParseDeclarationOrFunctionDefinition(clang::ParsedAttributes&, clang::ParsedAttributes&, clang::ParsingDeclSpec*, clang::AccessSpecifier) (/lib64/libclang-cpp.so.17+0x1756874)
#13 0x00007f514a9555b4 clang::Parser::ParseExternalDeclaration(clang::ParsedAttributes&, clang::ParsedAttributes&, clang::ParsingDeclSpec*) (/lib64/libclang-cpp.so.17+0x17555b4)
#14 0x00007f514a9533ef clang::Parser::ParseTopLevelDecl(clang::OpaquePtr<clang::DeclGroupRef>&, clang::Sema::ModuleImportState&) (/lib64/libclang-cpp.so.17+0x17533ef)
#15 0x00007f514a95247e clang::Parser::ParseFirstTopLevelDecl(clang::OpaquePtr<clang::DeclGroupRef>&, clang::Sema::ModuleImportState&) (/lib64/libclang-cpp.so.17+0x175247e)
#16 0x00007f514a85aa16 clang::ParseAST(clang::Sema&, bool, bool) (/lib64/libclang-cpp.so.17+0x165aa16)
#17 0x00007f514cc3a36b clang::FrontendAction::Execute() (/lib64/libclang-cpp.so.17+0x3a3a36b)
#18 0x00007f514cba10b9 clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) (/lib64/libclang-cpp.so.17+0x39a10b9)
#19 0x00007f514ccb4af9 clang::ExecuteCompilerInvocation(clang::CompilerInstance*) (/lib64/libclang-cpp.so.17+0x3ab4af9)
#20 0x00005642b7f49671 cc1_main(llvm::ArrayRef<char const*>, char const*, void*) (/usr/bin/clang-17+0x16671)
#21 0x00005642b7f45e50 (/usr/bin/clang-17+0x12e50)
#22 0x00005642b7f446e1 clang_main(int, char**, llvm::ToolContext const&) (/usr/bin/clang-17+0x116e1)
#23 0x00005642b7f54442 main (/usr/bin/clang-17+0x21442)
#24 0x00007f513f23fc0a (/lib64/libc.so.6+0x27c0a)
#25 0x00007f513f23fcc5 __libc_start_main (/lib64/libc.so.6+0x27cc5)
#26 0x00005642b7f41f11 _start (/usr/bin/clang-17+0xef11)
clang: error: unable to execute command: Aborted (core dumped)
clang: error: clang frontend command failed due to signal (use -v to see invocation)
OpenMandriva 17.0.5-1 clang version 17.0.5 (/builddir/build/BUILD/llvm-project-17.0.5.src/clang 67c77eb4750e684d5c3fa07b1014bf3def1e9277)
Target: x86_64-pc-linux-gnu
Thread model: posix
InstalledDir: /usr/bin
clang: note: diagnostic msg:
********************
PLEASE ATTACH THE FOLLOWING FILES TO THE BUG REPORT:
Preprocessed source(s) and associated run script(s) are located at:
clang: note: diagnostic msg: /tmp/test-a39e9d.c
clang: note: diagnostic msg: /tmp/test-a39e9d.sh
clang: note: diagnostic msg:
********************
```
The same thing happens in real world code where, for example, a C application tries to `#include` a header containing C++ constructs, such as
```
extern void a(const char* b, std::ostream & c, bool d);
int main(void)
{
}
```
Lancern
ChipsSpectre
Clang (not clang++) crashes on a file that contains just "::", throwing an assertion that such code should be guarded by checking for C++.
Of course this is not valid C, but I'd expect clang to give a proper error instead of an assertion and a backtrace.
The same thing happens in real world code where, for example, a C application tries to
#includea header containing C++ constructs, such as