Application: kdevelop (5.5.1) Qt Version: 5.14.1 Frameworks Version: 5.70.0 Operating System: Linux 5.6.11-1-default x86_64 Windowing system: X11 Distribution: openSUSE Tumbleweed -- Information about the crash: Trying to parse a file that has a <memory> include causes a crash if the parser has been set to c++2a The crash can be reproduced every time. -- Backtrace (Reduced): #4 clang::ConceptReference::getNamedConcept (this=0x0) at ../tools/clang/include/clang/AST/ASTConcept.h:155 #5 isSameTemplateParameter (X=0x7fba0628e7e8, Y=0x7fba0628ee28) at ../tools/clang/lib/Serialization/ASTReaderDecl.cpp:2890 #6 isSameTemplateParameterList (C=..., X=0x7fba0628e8b8, Y=0x7fba0628eef8) at ../tools/clang/lib/Serialization/ASTReaderDecl.cpp:2981 #7 0x00007fba5eb165d5 in isSameEntity (X=0x7fba0628e288, Y=0x7fba0628e8f8) at ../tools/clang/lib/Serialization/ASTReaderDecl.cpp:3183 #8 0x00007fba5eb155df in clang::ASTDeclReader::findExisting (this=<optimized out>, D=0x7fba0628e8f8) at ../tools/clang/lib/Serialization/ASTReaderDecl.cpp:3469 Reported using DrKonqi
Created attachment 128560 [details] full backtrace konqui seems to be bugged and can't send the crash as an attachment.
This is almost certainly a bug in libclang and needs to be reported there.
(In reply to Sven Brauch from comment #2) > This is almost certainly a bug in libclang and needs to be reported there. Agreed. This seems to be the deserialization of a stored AST, likely from a preamble. For a reproducer, you can try working with PCHs (http://clang.llvm.org/docs/PCHInternals.html). Since you're using the standard library, you'll want to work without -cc1. With test.hpp: "#include <memory>" and test.cpp empty, run clang -fsyntax-only -std=c++2a test.hpp -Xclang -emit-pch >test.hpp.pch clang -c -std=c++2a -include-pch test.hpp.pch test.cpp -o test.s I can't reproduce this here, but I haven't installed the update to GCC 10 yet, which also comes with a new libstdc++ that you're likely using here. Concepts are pretty new, so I'm not surprised it's still a bit rough around the edges. Looking at the code, we're here (https://github.com/llvm/llvm-project/blob/llvmorg-10.0.0/clang/lib/Serialization/ASTReaderDecl.cpp#L2885-L2891): if (TX->hasTypeConstraint() != TY->hasTypeConstraint()) return false; if (TX->hasTypeConstraint()) { const TypeConstraint *TXTC = TX->getTypeConstraint(); const TypeConstraint *TYTC = TY->getTypeConstraint(); if (TXTC->getNamedConcept() != TYTC->getNamedConcept()) // <--- return false; with either TXTC or TYTC being nullptr. This is a bit strange, since TX->hasTypeConstraint() and TY->hasTypeConstraint() are both true. But both functions check different flags (https://github.com/llvm/llvm-project/blob/llvmorg-10.0.0/clang/include/clang/AST/DeclTemplate.h#L1343-L1359): const TypeConstraint *getTypeConstraint() const { return TypeConstraintInitialized ? getTrailingObjects<TypeConstraint>() : nullptr; } bool hasTypeConstraint() const { return HasTypeConstraint; } My recommendation (since we're talking about pretty recent code) would be to try a current master build and see if you can reproduce the issue there. There is bit of a chance that it is already fixed. Since you're on Tumbleweed, you can also try 10.0.1-rc1 (https://build.opensuse.org/project/show/home:aaronpuchert:branches:devel:tools:compiler), but sometimes people forget to port back bug fixes.
The crash occurs because <memory> includes <ranges>, which includes a code pattern that triggers a bug. For a minimal reproducer, see Bug 422716 Comment 2.
(In reply to Matt Whitlock from comment #4) > For a minimal reproducer, see Bug 422716 Comment 2. Thanks, that's what I've been looking for. I've used this in my upstream bug report https://bugs.llvm.org/show_bug.cgi?id=46355, I hope you don't mind.
(In reply to Aaron Puchert from comment #5) > I hope you don't mind. Not at all! I'm glad you were able to come up with an incantation that makes Clang crash when run from the command line. Thanks for catching my pass and running with it.
*** Bug 422716 has been marked as a duplicate of this bug. ***
Just FYI, this has been reported again as https://bugs.llvm.org/show_bug.cgi?id=46790 which was fixed in https://github.com/llvm/llvm-project/commit/73c12bd8ff1a9cd8375a357ea06f171e127ec1b8. The fix will be in Clang 11.