example from https://isocpp.org/files/papers/N4663.pdf #include <experimental/coroutine> #include <iostream> struct generator { struct promise_type; using handle = std::experimental::coroutine_handle<promise_type>; struct promise_type { int current_value; static auto get_return_object_on_allocation_failure() { return generator{nullptr}; } auto get_return_object() { return generator{handle::from_promise(*this)}; } auto initial_suspend() { return std::experimental::suspend_always{}; } auto final_suspend() { return std::experimental::suspend_always{}; } auto yield_value(int value) { current_value = value; return std::experimental::suspend_always{}; } void unhandled_exception() { std::terminate(); } // void return_void() {}// uncomment -> crash }; bool move_next() { return coro ? (coro.resume(), !coro.done()) : false; } int current_value() { return coro.promise().current_value; } ~generator() { if(coro) coro.destroy(); } private: generator(handle h) : coro(h) {} handle coro; }; generator f() { co_yield 1; co_yield 2; } int main() { auto g = f(); while(g.move_next()) std::cout << g.current_value() << std::endl; } Also, crash on all other examples. The compilation passes normally.
please add a backtrace
(In reply to Milian Wolff from comment #1) > please add a backtrace #0 0x00007fff9aa33e01 in clang_getCursorLocation () from /usr/lib64/llvm/6/lib64/libclang.so.6 #1 0x00007fff9ad15a44 in ?? () from /usr/lib64/libKDevClangPrivate.so.31 #2 0x00007fff9aa42740 in ?? () from /usr/lib64/llvm/6/lib64/libclang.so.6 #3 0x00007fff9aa48fa5 in ?? () from /usr/lib64/llvm/6/lib64/libclang.so.6 #4 0x00007fff9aa4222b in ?? () from /usr/lib64/llvm/6/lib64/libclang.so.6 #5 0x00007fff9aa4a62d in clang_visitChildren () from /usr/lib64/llvm/6/lib64/libclang.so.6 #6 0x00007fff9ad031b6 in ?? () from /usr/lib64/libKDevClangPrivate.so.31 #7 0x00007fff9ad170c4 in ?? () from /usr/lib64/libKDevClangPrivate.so.31 #8 0x00007fff9aa42740 in ?? () from /usr/lib64/llvm/6/lib64/libclang.so.6 #9 0x00007fff9aa45ced in ?? () from /usr/lib64/llvm/6/lib64/libclang.so.6 #10 0x00007fff9aa45ecb in ?? () from /usr/lib64/llvm/6/lib64/libclang.so.6 #11 0x00007fff9aa42544 in ?? () from /usr/lib64/llvm/6/lib64/libclang.so.6 #12 0x00007fff9aa4a62d in clang_visitChildren () from /usr/lib64/llvm/6/lib64/libclang.so.6 #13 0x00007fff9acfd86a in Builder::visit(CXTranslationUnitImpl*, void*, QHash<void*, KDevelop::ReferencedTopDUContext> const&, bool) () from /usr/lib64/libKDevClangPrivate.so.31 #14 0x00007fff9ad25196 in ClangHelpers::buildDUChain(void*, QMultiHash<void*, Import> const&, ParseSession const&, KDevelop::TopDUContext::Features, QHash<void*, KDevelop::ReferencedTopDUContext>&, ClangIndex*, std::function<bool ()> const&) () from /usr/lib64/libKDevClangPrivate.so.31 #15 0x00007fff9af88949 in ?? () from /usr/lib64/qt5/plugins/kdevplatform/31/kdevclangsupport.so #16 0x00007fffeb1efeaa in ThreadWeaver::IdDecorator::run(QSharedPointer<ThreadWeaver::JobInterface>, ThreadWeaver::Thread*) () from /usr/lib64/libKF5ThreadWeaver.so.5 #17 0x00007fffeb1f0448 in ThreadWeaver::Executor::run(QSharedPointer<ThreadWeaver::JobInterface> const&, ThreadWeaver::Thread*) () from /usr/lib64/libKF5ThreadWeaver.so.5 #18 0x00007fffeb1ef250 in ThreadWeaver::Job::execute(QSharedPointer<ThreadWeaver::JobInterface> const&, ThreadWeaver::Thread*) () from /usr/lib64/libKF5ThreadWeaver.so.5 #19 0x00007fffeb1eed3d in ThreadWeaver::Thread::run() () from /usr/lib64/libKF5ThreadWeaver.so.5 #20 0x00007ffff4ee25e6 in ?? () from /usr/lib64/libQt5Core.so.5 #21 0x00007fffed62d8ea in start_thread () from /lib64/libpthread.so.0 #22 0x00007ffff478268f in clone () from /lib64/libc.so.6 This is reproduced everywhere. With all versions of clang. Try it yourself. I do not have debugging information.
I don't have that experimental header, so it doesn't crash for me. Your backtrace is missing debug symbols, so it's not helpful. But it already points at clang itself here, so probably you should report the bug upstream there.
Dear Bug Submitter, This bug has been in NEEDSINFO status with no change for at least 15 days. Please provide the requested information as soon as possible and set the bug status as REPORTED. Due to regular bug tracker maintenance, if the bug is still in NEEDSINFO status with no change in 30 days, the bug will be closed as RESOLVED > WORKSFORME due to lack of needed information. For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging If you have already provided the requested information, please set the bug status as REPORTED so that the KDE team knows that the bug is ready to be confirmed. Thank you for helping us make KDE software even better for everyone!
Dear Bug Submitter, This bug has been in NEEDSINFO status with no change for at least 30 days. The bug is now closed as RESOLVED > WORKSFORME due to lack of needed information. For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging Thank you for helping us make KDE software even better for everyone!