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.

41 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.

  11. David Rees says:

    As part of the C++ language support do you plan to look at improving type hierarchy and method hierarchy information? There are many related issues on them:

    • Anastasia Kazakova says:

      Ok, there are quite many tickets linked to these group issue. Some of them are features that are not yet implemented, some are bugs. Can you maybe be more specific and list some most annoying issues? Or describe the case which doesn’t work nicely for you now in CLion. So that we can consider the improvement in some particular direction.

  12. Oleksandr Gusiev says:

    Please add full stm32 + cubeMX out of the box support ASAP, because new Stm32CubeIDE is extremely sad, I believe only in CLion now…

    P.S. I use your “all products pack” more than a year and start loving it more! Thanks.

    • Anastasia Kazakova says:

      What are you missing in the current integration with CubeMX?

      • Oleksandr Gusiev says:

        I need an ability to open cubemx projects in clion as easy as it works in Atollic Truestudio, but with clion power. You know, stm development is a little bit painful on its own, and it will be nice to have as less additional configuration steps from ide side as possible, to simplify development process. People usually need a lot features, but the most important are: intuitive interface, low entrance level, and good integration with existing ecosystem. I want to create project in stm32cube, import it into clion by one click and upload it on target mcu by another one, without 100500 additional steps between, for default configuration.

  13. Elmot says:

    The list of boards comes from OpenOCD configurations list. If OpenOCD does not support those chips yet, then there is no such boards in the list. You may try to use something else, for instance, STM32F0, STM32L0, or STM32L4 series, or even try to write your own config based on one of those.

    That experimental support is the only about cortex level detection based on chip name.

  14. Alex says:

    Please add support for #pragma mark
    This is such a useful feature for code navigation, one of the reason i mostly develop in XCode c++

    • Anastasia Kazakova says:

      What exactly do you mean by this support? Could you describe the use case and the usage?

      • Alex says:

        #pragma mark is sort of like advanced bookmark
        Anywhere in the code i can put line that looks like this:
        #pragma mark
        #pragma mark computing covariance
        Any time i have this file active in the editor xcode presents searchable pulldown list which is populated with description strings from pragma marks collected in the file. Selecting any item in the list navigates editor to that location. Much more convenient way to have descriptive bookmarks.

Leave a Reply to Arkadiy Belousov Cancel reply

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