It’s now time for 2019.2! CLion roadmap


We’ve recently just released CLion 2019.1! It has been served up with several major improvements, like Clangd-based code highlighting, integration with ClangFormat, project-model-independent build targets and run/debug configurations (especially useful for compilation database and Makefiles projects), memory view in the debugger, injected languages, and not to forget of course some initial Embedded Development support. Release time is always exciting, and we are enormously inspired by all your positive feedback and kind words!

There are still a couple of glitches and regressions, but we are planning to sort them out with the first bug-fix update. Right now, it feels like a good time to give our sincerest thanks to the most active evaluators and share with you all our plans for v2019.2.

Special thanks

There are so many possible setups and configurations where CLion is used nowadays, that we may sometimes miss some of them during testing. This is why our Early Access Preview program is so helpful to us, and we greatly appreciate all the help of our evaluators! There is an ongoing tradition to thank our most active EAP evaluators here in the blog and present each of them with a full 1-year subscription to CLion (as a new subscription or extend their current one). This time we’d like to issue a special thanks to the following contributors:

  • Victor Sergienko
  • Renat Khayretdinov
  • Dmytro Nezhevenko
  • Erik Hyun

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!)

CLion 2019.2 roadmap

Our general areas of focus for this year will stick closely to the same as announced previously. A detailed plan for the next cycle looks as follows:

Note: The following is a preliminary plan; we cannot guarantee that all of the features listed below will be included in CLion 2019.2.
  • Editor Responsiveness and Performance

We have some major architectural changes planned, which on the one hand could take longer than a single release cycle, but on the other hand, it will definitely improve the performance of many of the actions across the whole IDE. This should eliminate a big chunk of the existing UI freezes.

  • Further integration of Clangd-based C++ language engine

    • Improve the accuracy and put back the ‘Unused includes’ diagnostic
    • Move more of the IDE’s actions to Clangd-based engine (we are currently experimenting with a few and seeing how it goes)
    • Bug-fixes and engine performance tuning
  • C++ language support
    • Action to switch header/source (reworking current go to related symbol action) – CPP-12920
    • Continue with refactoring fixes, especially the Move refactoring
  • Embedded Development
    • Peripheral view for ARM devices (support for SVD files)
    • Support for custom gdbservers (ST-Link and J-Link GDB Servers)
  • Debugger
    • Continue with the ongoing work on the Windows debugger (for MSVC). This debugger is being implemented from scratch and is based on LLDB. We hope to have a preview ready for v2019.2, but can’t promise anything at this stage.
    • Improve current memory view
  • Project Model
    • The ongoing work to create a project model API to allow 3rd-party plugin writers add support for currently unsupported build systems will continue during this release.
    • Another direction is to start Makefiles support. Saying this, we are giving no promises regarding v2019.2, but just want to assure you that this is under careful investigation and analysis from our side.
  • Remote
    • Various enhancements in remote development and an ability to launch the application automatically under gdbserver via ssh for remote debug (CPP-7050).

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.

28 Responses to It’s now time for 2019.2! CLion roadmap

  1. Henry Borchers says:

    Windows debugger (for MSVC)!! yay!!!

  2. Olof says:

    CLion is different from many of your IDE’s in that it is a new product that has to all of a sudden work on huge code bases of a language that is really hard to parse. That’s a tough challenge. It’s the equivalent of being dropped into the deep end of the pool. You better learn to swim fast.

    Just out of curiosity does the optimization work you have to do for CLion benefit for instance IntelliJ? Or is it mostly independent?

    • Anastasia Kazakova says:

      Yes, quite many our changes in CLion are aligned with some directions for performance improvements in IntelliJ platform and IntelliJ IDEA and other ideas. While others are very C++ specific. Things that work perfectly well for Java or Python, may sometimes completely fail for C++.

  3. I have 3 points which I would like to have:

    1st CTEST support. In complicated deployment with 1000 of test it is really painful to set up the execution of targets in the IDE. We generate nice deployment and execution wrapper in with cmake using CTEST i would like that the IDE can use this info so no manual clicking is needed.

    2nd A help of setting up cross compile environment by allowing execution of cmake shell wher a script a sourced in to which sets up the environment like alias / chroot etc. Today I have to work it around with creating a new toolchain where the cmake command is replaced with a wrapper script. Which then calls cmake in the shell where environment is set and it passes the arguments from clion to the wrapped cmake.

    3rd is remote development enhancement. As of today the remote development is not usable with the midsize and large project I’m talking about 1 000 to 100 000 c++ files. Actually remote development make sense in such a magnitude, since this case a build machine can be shared between developers which has 50+ cores to build / test. But the way clion handles file synchronization (a new SSH session for each file). It is simple not practical because the SSH session establishment is too much of an overhead (~300- ~500ms per file) which makes synchronization to take up several HOURS. At least extend the ssh calls for remote sessions in such a way that you reuse ssh session between calls (see This simple extension would improve the speed dramatically.

  4. Vitaly Grigorev says:

    For myself, I noticed two big problems of IDE:
    1. A persistent problem with type indexing inside a smart pointer. Sometimes you correct the behavior of the IDE, then spoil it again, and the IDE again do mistakes when works with dereference operators of smart pointers.
    2. IDE does not know how to work with template classes. It is impossible to go through the code due to the fact that there is no binding of methods to data types (indexing does not occur).

    May be this problems lies in clangd.

  5. Tano says:

    Anastasia, please improve performance, I like that you have this on the roadmap, this is CLion’s no. 1 problem and the reason that my colleagues do not switch to it.
    As I mentioned before it’s a bit awkward in 2019 to have lag during typing (CPP-9819, CPP-15772)

    • Anastasia Kazakova says:

      I guess you know we are constantly working on performance and it’s a top priority for us. CPP-9819 is related to curl and some more general issues with typing in macros. Issue in CPP-15772 is not clear in your case, better attach a CPU snapshot. Snapshots we currently have there are related to some other two issues, linked in the comments. Would be nice to understand which one yours is related to.

      • Tano says:

        Oki, I just did. I constantly have small spikes when I keep pressing a key (Enter usually), it’s not fluid at all.

  6. Tano says:

    Question, not related to roadmap: I constantly developing on 2 machines in paralel (linux and macos, 1-2h on each, then commit, test on the other one) and I have only 1 CLion license and I always have to close the other machine in order to work for the current one.
    Is there any possibility for me to not shutdown and then open all the time?

    I am doing this 10 times a day. Thanks.

  7. Tano says:

    Sorry, another question, I don’t know where to ask them (on the community no one answers): If I want to add a new clang-tidy option, should I add it in Inspections->clang tidy field or in Langagues & Frameworks->C/C++->clangd field?

    • Anastasia Kazakova says:

      To Inspection Clang-Tidy option. However, might depend on the setting. If it’s common, then clangd might interfere.

  8. blackj0221 says:

    When would JBR 11 be applied to CLion?

  9. singalen says:

    Thank you very much!

  10. Arkadiy Belousov says:

    Please consider using Docker as a kind of semi-remote development environment. We currently develop Linux code on Windows by mapping the Windows directory with source to a Docker container and running cmake/make./ctest in that container. It works very well, no synchronization with remote build/test box needed.

Leave a Reply

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