If you could isolate on which file(s) this is happening on, that'd be great. Then we can report a ticket upstream at the LLVM project.

Odd, I've seen this exact bug before and it pertains to the use of C++17 structured bindings. Looking at the backtrace itself, you can even see calls into the structured binding machinery at #7 with the call to `clang::ASTDeclReader::VisitDecompositionDecl(clang::DecompositionDecl*)`; "decomposition declaration" was just a prior name for this feature. Specifically, the cause of the segfault is an attempt to dereference a nullptr, which results from some data-structure (involved in the parsing of structured bindings), somewhere, not being initialized properly when the parser isn't in C++17 mode. I never narrowed the specific cause because fixes to CMake support obviated the issue for me, but I could look back into it if requested.

That said, I'm not sure what's causing this specific failure; some cursory investigation into digikam's sources uncovers nothing in CMake instructing the use of C++17 features at compile-time, and moreover, trying some grep patterns which should match a structured binding declaration come up empty, so either something is going very wrong the parser, or is it possible you have some local changes to the code using structured bindings, or additional projects open?

I can reproduce on KDevelop master and a Clang-6 checkout only a few hours old, the files that trigger it seem to be the "Managed" C++ files under 'digikam/utilities/mediaserver/upnpsdk/Platinum/Source/Extras/Managed/', and while I'm not entirely sure why Clang is trying to parse anything in there as a structured binding, it doesn't surprise me that fake, MS C++ masquerading as real C++ should cause issues. It accidentally confirms that the nullptr deref in Clang is a real bug in the parser, however, so I'll start trying to figure it out.

WORKAROUND: for the moment, so long as you don't have a burning desire or need to edit these files in KDevelop, you can add the entire directory to the project's exclude filters. While one could edit KDevelop's project file with a text editor and then launch KDevelop afterward, I was lazy and so temporarily disabled KDevelop's background parsing, added the directory to the filter from inside KDevelop, and then re-enabled background parsing. That ended the segfaulting for me.

Can reproduce. Offending file is NeptuneException.cpp in digikam.git.

Test run which crashes:
/kdevelop/kdevplatform/util/duchainify/duchainify /home/kfunk/devel/src/kf5/digikam/utilities/mediaserver/upnpsdk/Platinum/Source/Extras/Managed/NeptuneException.cpp

Backtrace with a LLVM debug build (LLVM 5.0 branch):
#0  0x00007fffc52a8f5b in clang::Decl::setInvalidDecl (this=0x0, Invalid=true) at /home/kfunk/devel/src/llvm/tools/clang/lib/AST/DeclBase.cpp:112
#1  0x00007fffc52a8fad in clang::Decl::setInvalidDecl (this=<optimized out>, Invalid=<optimized out>) at /home/kfunk/devel/src/llvm/tools/clang/lib/AST/DeclBase.cpp:129
#2  0x00007fffbb7020aa in clang::ASTDeclReader::VisitDecl (this=0x7fffaa7fb0b0, D=0x7fff94029eb8) at /home/kfunk/devel/src/llvm/tools/clang/lib/Serialization/ASTReaderDecl.cpp:537
#3  0x00007fffbb703da6 in clang::ASTDeclReader::VisitNamedDecl (this=0x7fffaa7fb0b0, ND=0x7fff94029eb8) at /home/kfunk/devel/src/llvm/tools/clang/lib/Serialization/ASTReaderDecl.cpp:609
#4  clang::ASTDeclReader::VisitValueDecl (this=0x7fffaa7fb0b0, VD=0x7fff94029eb8) at /home/kfunk/devel/src/llvm/tools/clang/lib/Serialization/ASTReaderDecl.cpp:746
#5  clang::ASTDeclReader::VisitDeclaratorDecl (this=0x7fffaa7fb0b0, DD=0x7fff94029eb8) at /home/kfunk/devel/src/llvm/tools/clang/lib/Serialization/ASTReaderDecl.cpp:759
#6  0x00007fffbb70863b in clang::ASTDeclReader::VisitVarDeclImpl (this=0x7fffaa7fb0b0, VD=0x7fff94029eb8) at /home/kfunk/devel/src/llvm/tools/clang/lib/Serialization/ASTReaderDecl.cpp:1260
#7  0x00007fffbb701db5 in clang::ASTDeclReader::VisitVarDecl (this=0x7fffaa7fb0b0, VD=0x7fff94029eb8) at /home/kfunk/devel/src/llvm/tools/clang/lib/Serialization/ASTReaderDecl.cpp:333
#8  clang::ASTDeclReader::VisitDecompositionDecl (this=0x7fffaa7fb0b0, DD=0x7fff94029eb8) at /home/kfunk/devel/src/llvm/tools/clang/lib/Serialization/ASTReaderDecl.cpp:1352
#9  clang::declvisitor::Base<clang::declvisitor::make_ptr, clang::ASTDeclReader, void>::Visit (this=0x7fffaa7fb0b0, D=0x7fff94029eb8) at tools/clang/include/clang/AST/DeclNodes.inc:445
#10 0x00007fffbb701332 in clang::ASTDeclReader::Visit (this=0x7fffaa7fb0b0, D=0x7fff94029eb8) at /home/kfunk/devel/src/llvm/tools/clang/lib/Serialization/ASTReaderDecl.cpp:468
#11 0x00007fffbb7276e1 in clang::ASTReader::ReadDeclRecord (this=0x7fff9406b030, ID=19) at /home/kfunk/devel/src/llvm/tools/clang/lib/Serialization/ASTReaderDecl.cpp:3623
#12 0x00007fffbb6c5d7d in clang::ASTReader::GetDecl (this=0x7fff9406b030, ID=19) at /home/kfunk/devel/src/llvm/tools/clang/lib/Serialization/ASTReader.cpp:7102
#13 0x00007fffbb727ccb in clang::ASTReader::PassInterestingDeclsToConsumer (this=0x7fff9406b030) at /home/kfunk/devel/src/llvm/tools/clang/lib/Serialization/ASTReaderDecl.cpp:3674
#14 0x00007fffbb6dbefc in non-virtual thunk to clang::ASTReader::StartTranslationUnit(clang::ASTConsumer*) () at /home/kfunk/devel/src/llvm/tools/clang/lib/Serialization/ASTReader.cpp:7356
#15 0x00007fffbb821328 in clang::ParseAST (S=..., PrintStats=<optimized out>, SkipFunctionBodies=<optimized out>) at /home/kfunk/devel/src/llvm/tools/clang/lib/Parse/ParseAST.cpp:144

The surprising thing is that libclang crashes, while plain clang does not:

Note: MWE is:
% cat ~/test.cpp                                                                                                                                          
#include "test.h"
% cat ~/test.h                                                                                                                                                  
#pragma once

[Serializable]
public ref class NeptuneException : Exception
{
};


% KDEV_CLANG_DISPLAY_ARGS=1 ~/devel/build/kf5/kdevelop/kdevplatform/util/duchainify/duchainify ~/test.cpp                                                   
Added 1 files to the background parser
parsing with 4 threads
Invocation: clang -ferror-limit=100 -fspell-checking -Wdocumentation -Wunused-parameter -Wunreachable-code -Wall -std=c++11 -nostdinc -nostdinc++ -xc++ -isystem/usr/include/c++/6 -isystem/usr/include/x86_64-linux-gnu/c++/6 -isystem/usr/include/c++/6/backward -isystem/usr/local/include -isystem/home/kfunk/devel/build/llvm/lib/clang/5.0.1/include -isystem/usr/include/x86_64-linux-gnu -isystem/usr/include -imacros /tmp/duchainify.J20863 /home/kfunk/test.cpp
libclang: crash detected during parsing: {
  'source_filename' : '/home/kfunk/test.cpp'
  'command_line_args' : ['clang', '-ferror-limit=100', '-fspell-checking', '-Wdocumentation', '-Wunused-parameter', '-Wunreachable-code', '-Wall', '-std=c++11', '-nostdinc', '-nostdinc++', '-xc++', '-isystem/usr/include/c++/6', '-isystem/usr/include/x86_64-linux-gnu/c++/6', '-isystem/usr/include/c++/6/backward', '-isystem/usr/local/include', '-isystem/home/kfunk/devel/build/llvm/lib/clang/5.0.1/include', '-isystem/usr/include/x86_64-linux-gnu', '-isystem/usr/include', '-imacros', '/tmp/duchainify.J20863'],
  'unsaved_files' : [],
  'options' : 781,
}
zsh: segmentation fault  KDEV_CLANG_DISPLAY_ARGS=1  ~/test.cpp

% clang -ferror-limit=100 -fspell-checking -Wdocumentation -Wunused-parameter -Wunreachable-code -Wall -std=c++11 -nostdinc -nostdinc++ -xc++ -isystem/usr/include/c++/6 -isystem/usr/include/x86_64-linux-gnu/c++/6 -isystem/usr/include/c++/6/backward -isystem/usr/local/include -isystem/home/kfunk/devel/build/llvm/lib/clang/5.0.1/include -isystem/usr/include/x86_64-linux-gnu -isystem/usr/include -imacros /tmp/duchainify.J20863 /home/kfunk/test.cpp
In file included from /home/kfunk/test.cpp:1:
/home/kfunk/test.h:3:1: warning: decomposition declarations are a C++17 extension [-Wc++17-extensions]
[Serializable]
^~~~~~~~~~~~~~
/home/kfunk/test.h:3:1: error: C++ requires a type specifier for all declarations
/home/kfunk/test.h:3:1: error: decomposition declaration cannot be declared with type 'int'; declared type must be 'auto' or reference to 'auto'
/home/kfunk/test.h:3:1: error: decomposition declaration '[Serializable]' requires an initializer
/home/kfunk/test.h:3:15: error: expected ';' after top level declarator
[Serializable]
              ^
              ;                                                                                                                                                                                                             
1 warning and 4 errors generated.

Yeah, I had been wondering why that is and frankly do not understand it, the offending fragment of code appears to be:

  // Marking a DecompositionDecl as invalid implies all the child BindingDecl's
  // are invalid too.
  if (DecompositionDecl *DD = dyn_cast<DecompositionDecl>(this)) {
    for (BindingDecl *Binding : DD->bindings()) {
      Binding->setInvalidDecl();
    }
  }

in Decl::setInvalidDecl(bool):clang/lib/AST/DeclBase.cpp

The issue is, when not in C++17, the reference returned by `DD->bindings()` seems to contain a nullptr, which is subsequently dereferenced with `Binding->setInvalidDecl()`. The resulting segfault should kill just about anything, right? What kind of insulation the clang driver must have is pretty special. Unless they somehow avoid being on that codepath entirely or somehow interfere with the erroneous initialization which must be occurring when otherwise not in C++17 mode. It has been my experience, thus far, that even invalid structured bindings do not result in this problem so long as the parser is in C++17 mode. Why there's no guard-check in that loop or safe initialization of that reference is as-yet unknown to me. I dunno if this would be considered sufficient information, yet, to file a bug report upstream.

Reported upstream, with the limited information at hand:
  https://bugs.llvm.org/show_bug.cgi?id=34960

This bug renders KDevelop unusable for me, as most projects I deal with now a days are C++17, and it would be unfeasable to manually add each of the offending files to the filter. Is there any way to set the parser to c++17 mode so the nullptr deref doesn't happen? Happy to dig submit patches to either Kdevelop / Clang to help remediate this.

The bug has been fixed, and the fix will be in Clang 11.