Moving into 2019. CLion roadmap

This year’s third big update – CLion 2018.3 – has landed just a few days ago! It’s all about Remote Development, CPU profiling, and better C++ language support.

Following our good tradition, we want to thank those evaluators who have helped us ship so many goodies and still keep the release stable. Our special thanks go to:

  • Oliver Stöneberg
  • Michael Klatt
  • Dmytro Nezhevenko

In appreciation of your efforts, we are giving each of you a free 1-year subscription for CLion (to extend your current subscription or get a new one). You will receive a personal email with details on how to claim your license. If for some reason you do not get an email from us within a week, ping us here in the comments!

Roadmap: CLion in 2019

Our main areas of focus for next year:

  1. Boost performance & eliminate freezes
  2. Wider integration with Clangd-based language engine
  3. Embedded development support

These 3 areas will occupy most of our time and resources and will entail hundreds of various tasks. For example, Embedded development is a huge and diverse area, and our first step will be into the STM32 family of boards. At the same time, it will require lots of changes and improvements in debugger support, project models, and so on. Even if you don’t do Embedded development, you may still benefit from CLion taking this path.

Plan for CLion 2019.1

Note: The following is a preliminary plan; we cannot guarantee that all of the features listed below will be included in CLion 2019.1.
  • Embedded Development

  • Debugger
    • Rework experimental hex implementation
    • Add memory view to CLion
    • Add disassembler view for LLDB debugger (only available for GDB for now)
    • Work on debugger for MSVC on Windows (this might not be finished by the time 2019.1 is released, but some experimental preview will likely be available)
  • C++ support
    • Better indicators related to the Clangd-based engine (in order to measure the memory and CPU usage for this new engine on the user’s side)
    • Wider integration with Clangd-based language engine: the next candidate is syntax highlighting
    • Various bug-fixes in CLion’s own language engine
  • Performance improvements and elimination of freezes: here we plan to focus on memory and CPU usage, investigate deeper first project indexing times and completion performance.
  • Formatter: Clang-format integration
    • In reformat action
    • On the commit stage
    • Automatic Clang-format config detection
  • Project models: continue detaching the API

That’s it! Do you have any new feature requests? Send them to our tracker. We’re listening!

Your CLion Team

The Drive to Develop

This entry was posted in Announcement and tagged , , , . Bookmark the permalink.

73 Responses to Moving into 2019. CLion roadmap

  1. Tano says:

    The roadmap looks really nice, but I want to point 2 things:

    1. Please watch out for clangd, sometimes it misbehaves badly, for example I opened CPP-14739 in which it works the reverse way, meaning that the “-Wno-missing-field-initializers” is set, but it shows the warning. When I delete that line (so the warning should be shown), it does not show the warning anymore.

    2. I also talked with Eldar about this, my general feeling is that the debugger in CLion is not evolving in any way, although CLion has a lot of other features added in every version. And the debugger is one of the most used things in an IDE. It’s nice that you add memory view.

    Also here are some bugs easier to fix, because they are only related to GUI: CPP-13954 IDEA-195290 IDEA-195289


    • Anastasia Kazakova says:

      Clangd work will be definitely continued, that’s part of this roadmap. And we commented on the source of the problem in

      Regarding the debugger, this might be not that visible outside, from the user’s perspective, but there is a huge work on improving general debugger experience, output handling, performance improvements, updating bundled debugger versions and fixing dozens of compatibility issues. Mem view was also started during this iteration but turned out to be harder than we expected it to be, so will be continued in 19.1.

      And the UI issues are not always just UI, but some other behaviour which might affect performance, etc. But we’ll take a look when have some free time.

      • Tano says:

        Yeah, thanks, your colleague tells me to add that option but it is very clear that I have it already (I provided a compiler options .txt) 😀

        I perfectly understand the performance penalties for the debugger, but it is not always the case, for example IDEA-195290 should be fixed in a few hours.

        Thanks Anastasia

      • Tano says:

        Hi again, I kindly ask you (or another colleague, besides Maxim, because he is telling me the same thing from the couple of days) to take a look on CPP-14739 when someone has a little time please, there are 2 problems there:

        1. Maxim told me that the problem is caused by the fact that I have “-Wextra” in my CMake file, why is the static analyzer reading my CMake?

        2. In the CMake also later I have “-Wno-missing-field-initializers” later in the CMake, so it should work. I also deleted “-Wextra” from the CMake and still it does not work.

        3. I set in clangd option “-Wno-missing-field-initializers”, meaning DO NOT show the warning and it seems to show it. Then I delete that line (the warning should be shown now) and …gues what…the warning is not shown. So it works in the reverse way.


  2. Rogiel says:

    “Better indicators related to the Clangd-based engine (in order to measure the memory and CPU usage for this new engine on the user’s side)”

    One issue I have been having with the clangd (and with clang-tidy if clangd engine is disabled) is a very weird bug in clang. Sometimes template evaluation recurses indefinitely and memory explodes (to the order of 30-40GB — Darwin is able to compress most of it though) and I need to kill clangd executable manually.

    I know this is not CLion related, but would be nice if CLion could keep track of its children processes and kill them if anything goes out of control like that.

    • Anastasia Kazakova says:

      Definitely! And this task you’ve mentioned is exactly dedicated to the situations like that you described.

  3. Mike says:

    Please consider CPP-2659. A single Windows nmake build takes *minutes*, Ninja takes less than a second. At this point, I have a DOS window open that runs the cmake ninja build from the command line rather than building within CLion. That works just fine–it keeps the IDE happy and allows me a quick build.

    I understand you have issues in how to import build information and that Ninja Codeblocks isn’t the same as Nmake Codeblocks. Perhaps a parallel build?

    This one is huge for me–a minute+ to build is a massive slowdown and morale killer.

    Thanks for listening!

  4. Fabian says:

    Any chance to get disassembly of code where you have the source code? This often helps debugging what one wrote in C++ and what it turned out in assembler. See

  5. Henry Borchers says:

    Holy smokes!! You guys are finally working on a MSVC debugger support?!?! This will make my Python+C work on Windows so much easier. I love you guys!

  6. johnthagen says:

    With the STM32 integration work, are there any plans to also support Rust?

  7. johnthagen says:

    Any chance there would be time to support coloring parameter names in Doxygen comments? It would really help the readability of inline docs in all C/C++ projects.


  8. johnthagen says:

    Would it be possible to bundle the Markdown plugin like is currently done for PyCharm? Markdown is very ubiquitous now and it’s really convenient when it’s bundled since the Markdown plugin usually only supports a narrow slice of IntelliJ/CLion versions.

  9. Roman says:

    For embedded you should probably seek collaboration with or to enable Clion as alternative IDE.

    • Anastasia Kazakova says:

      We’ve chatted with in the past. They have a CLion dedicated layout and generate CMake compatible with CLion. They do not promote any particular IDE, but CLion is already mentioned on their site and works nicely.

  10. Helge Penne says:

    This seems like a great roadmap. The 2018.3 release seems like a good step in the right direction with regards to freezes and performance, but there is still some way to go. It’s good to see that this is a priority.

    Is there any chance that you will be able to fix this annoying bug in your refactoring functionality? Refactoring is supposed to be your strength, but this bug ruin important parts of it for those who comment their code:

    You also have some but silly and annoying problems with something as basic as #include statements:
    (there are many more duplicate reports of the same problem).

    Those really need to be fixed. Can you please get these prioritized?

    Then there is some important debug functionality that lots of users really want:

    Finally, it would be great to be able to turn off the editor warnings/errors from CLions parser completely, and only show the warnings from clang tidy. I’m sorry to say that the CLion parser has too many false positives, and many of them cannot be turned off in the inspection settings. The many false positives from CLion’s parser makes the clang positives less useful, so we would appreciate the ability to turn of the highlighting from CLion’s parser completely. That is currently not possible. This should be very simple to do, I think.

    • Anastasia Kazakova says:

      Thank you for your positive feedback. – is indeed unpleasant, but seems more like a missing feature. We hope to address if when have some free resources for that.

      Autoimport / includes related fixes are currently postponed for a while, we hope to reimplement that part of this functionality with Clangd help.

      Debugger issues will come sometime after the list mentioned in the roadmap, as it’s more important from our perspective.

      Regarding warning and errors, they are now taken from Clangd by default (have you turned it off?)

      • Helge Penne says:

        I have turned off “Show warnings and errors from clangd” in Settings, if that is what you are referring to. I have also turned off everything in Settings/Editor/Inspections except clang tidy, but I still get lots of warnings and error annotations from some other source than clang tidy. Why do you have annotations that can’t be turned off?

        One warning I’m looking at right now is an “err_typecheck_call_too_many_args”. This code is correct and compiles just fine so this is a false positive, and I have so far not found any way to turn this off except let CLion insert “#pragma ide” lines (which is unacceptable). There is also an “err_ovl_no_viable_member_function_in_call”. As far as I can tell, these are from clangd, but I have turned off warnings and errors from clangd in settings. Is that broken? It also does not seem to make any sense at all that clangd outputs warnings for code that compiles just fine with clang.

        If I could turn off all sources except clang tidy then I could let CLion perform code analysis on commit, but all the false positives makes this impossible.

        This seems to be broken and needs a fix. Should I file a bug report for this? I have assumed that you have lots of bug reports already on warning/error highlights in the editor, because this has never been very reliable in CLion.

        • Anastasia Kazakova says:

          > I have turned off “Show warnings and errors from clangd” in Settings, if that is what you are referring to.
          Exactly. I really recommend you to turn it back on, it’s an accurate errors from clangd-based engine. If you see any false positives, please report them.

          PLease, file bugs about false positives.

          • Helge Penne says:

            I’ve turned it back on, and it seems to be working now. i did an “invalidate cache” and it is possible that this helped. I will file a bug report if it shows up again.

          • Anastasia Kazakova says:

            Thank you! Glad it works now

  11. TheLordofdirTB says:

    please full support autocomplete C++17 like “auto result = map.try_emplace”

  12. Alexey says:

    There are some things which lacks in CLion, and some which lacks in other Intellij products also.

    First, it would be good to have a kind of integration for pretty-printers.
    CLion already supports python editing and gdb debugging. So, what about to combine them and give possibility to view and debug python pretty-printers for gdb? (yes, it is possible now to edit them, but as absolutely separate python source aside, agnostic to the fact that this very code will be run by this very gdb in this very IDE next moment).

    Second, more detailed support for viewing diffs/commiting to vcs.
    Now it is possible only to select/deselect a chunk or even bunch of chunks for partial commit. If I’ve added two lines of text, I have no choice to commit only one of them and leave second alone. That is the reason why I still use ‘git gui’ – since there I can not only ‘add block to the index’ (the same thing which clion do when I check a box near a patch), but also ‘add line to the index’ – which allow to split patches/blocks into separate lines.

    • Anastasia Kazakova says:

      Not sure I got the problem with pretty-printers. You can edit them and substitute .gbtinit/.lldbinit in your home directory and CLion will take them.

      Regarding the second one, indeed, this might be very useful. Can you please submit a report to IDEA tracker?

  13. Andrew says:

    CLion 2018.3 had “initial remote development support.” Remote development isn’t listed on the 2019 roadmap. Does that mean future work on the remote development experience will not happen in 2019?

    In particular, might the gdbserver-less debugging (over ssh) be extended to already-built (and/or already-running) binaries on the remote host? Right now, you have to have CLion build the project and start the debugging process for this to work, which means it is not usable for projects CLion can’t build itself (and that are instead built by an external system). While gdbserver could in theory be used, transferring gigabytes of symbols on every debugger run is not feasible.

    It seems like you have almost all the hard work there already to support gdbserver-less debugging; all that is missing is a UI entrypoint.

    • Anastasia Kazakova says:

      We treat remote as part of the huge embedded task (while it’s not the limited to it). However, for 2019.1 the plan is to polish current functionality and fix issues. Then we plan to address tasks like remote debug-only mode that you describe. We plan to get it in 2019.

  14. HGH says:

    Convince BlackBerry, IBM and others to ditch eclipse in favor of your platform.

  15. Lamonte says:

    SCons support is still going strong, why not cave and give it to us?

    • Anastasia Kazakova says:

      It’s indeed quite popular, but there are other project models more widespread among C++ developers, still not supported in CLion.

  16. Jerome says:

    One question torments me) why are you implementing work with embedded? Votes for working with embedded systems are much smaller than with many others. I give for example Qt, Makefile.
    Why not to realize what people most want?

    • Anastasia Kazakova says:

      We rely on many factors, not only YT votes. Embedded development is a top priority direction for us and always was, but the resources were much more limited than now. Initially, when started CLion, we analyzed the C++ market and found out that 3 directions are trending for C++: financial/trading, embedded and gamedev. So embedded dev is selected not only because of the votes, but also because of the many other factors.

      Regarding the project models, we expect Makefiles to be the next project model to support, however currently there are many activities in the core project model functionality which goal is to build an API for project models. We need to finalize it to some extent first, then we can move further with adding other project models.

      qmake is a very questionable project model in current circumstances. Qt recently deprecated qbs and seems will be moving towards CMake now. Doesn’t seems like a good argument to support qmake in that sense.

      • Jerome says:

        I understand you, thanks for the reply. But as for Qt, I had in mind the creation of a Qt project with a project relish file cmake. Macro support is very necessary.

        • Anastasia Kazakova says:

          What are the problems with Qt macro now in CLion? In general, you should be able to open a Qt CMake-based project in CLion and develop it w/o any problem.

          • Jerome says:

            CLion does not have Qt macro code generation support at all.
            CLion can not generate code from macro Q_PROPERTY
            Meta type
            I can continue the endless list))

          • Anastasia Kazakova says:

            What do you mean under “macro code generation support”? Can you please explain.
            When imported, it’s parsed correctly in my case. Maybe you can share a code sample and a problem description? Thank you

          • Jerome says:

            For example, you can enter the macro Q_PROPERTY and display the possibility of using parameters. When you mean this kind
            Q_PROPERTY(Priority priority READ priority WRITE setPriority NOTIFY priorityChanged)
            further, for example, from the context menu you choose to generate code, you will get this result

            void setPriority(Priority priority)
            m_priority = priority;
            emit priorityChanged(priority);
            Priority priority() const
            { return m_priority; }

            void priorityChanged(Priority);

            Priority m_priority;

          • Anastasia Kazakova says:

            Ah, so you mean a very specific Qt macro functionality. This might be interesting, feel free to put into the tracker as a feature request:
            And maybe more cases you have here in mind.

  17. Roman says:

    Auto-completion performance and refactoring quality are two most annoying problems. Wish to see improvements next year.

  18. Anonymous says:

    Roadmap is nice, I hope CLion 2019.1 support other build system, like make, autotools.

  19. Michael Reid says:

    As you focus on adding embedded support this year. Love the support for microcontroller development.

    However, is there a effort to look into Yocto builds? This would be useful for us that build full linux bsps for ARM platforms. I understand that Yocto is a group of build tools (bitbake as anexample).

  20. Anton says:

    The question is, are you going to implement support for interface libraries?
    I mean projects that have targets like this: add_library(${PROJECT_NAME} INTERFACE).

    For now working on header only projects is similar to working in notepad.

    • Wojtek says:

      I also faced this problem before.
      But there is a solution. You have to create a standard project (an executable lets say) and then link your header only library to this executable. This way you will have all the fancy IDE stuff (autocompletion, syntax validation, etc.)

    • Anastasia Kazakova says:

      This will be resolved by supporting CMake server (, The problem is that when header only projects are in CMake and the headers are not listed explicitly in CMakeLists.txt files, CMake doesn’t count these header files as project files, neither does CLion in that case. That’s why the problem is. Two workarounds for now: when the header is used in some .cpp (or other project file), CLion counts it as a project one automatically, even when not listed explicitly in CMake. Or you can mard directory as sources (in the context menu on the folder).

  21. Gregory Kramida says:


    are there any plans to address performance issues related to usage of the popular Eigen library and similar libraries in 2019?

    A lot of us are upset about it, see


  22. PM says:

    Help pls.

    “You will receive a personal email with details on how to claim your license. If for some reason you do not get an email from us within a week, ping us here in the comments!”

    Bought CLion at summer 2018, but did’t receive email…

  23. Miao says:

    Do you have any plan to implement core dump file analysis with GDB?

  24. Ryan says:

    This generally looks good. The performance issues/freezing are definitely the main thing stopping me from recommending CLion to other people right now.

  25. llvim says:

    Clangd-based engine is very very slow, it freeze my mac book pro 2015 everyday

    • Anastasia Kazakova says:

      Why are you sure it’s a clangd engine? If UI is freexing, the thread dumps are generated automatically in the logs directory (Help | Show Log). Is there anything?

  26. Rob Wehrli says:

    Anything to update in terms of the embedded support road map progress?

Leave a Reply

Your email address will not be published. Required fields are marked *