What’s Next: A Roadmap for CLion 2020.2

Posted on by Anastasia Kazakova

CLion 2020.1 has landed and has been followed up with its first bug-fix update, so it’s time to talk about our plans for the next release.

Special thanks

We have a good tradition to celebrate successful releases by giving our most sincere thanks to our Early Access Program users. Today we’d like to extend our special thanks to these fine folks who’ve been most active, along with a complimentary 1-year CLion subscription:

  • Mansur Mustaquim
  • Taw Moto
  • Pavel Samolisov
  • Tom Evers

We’ll email you in the next few days with a code for getting a new subscription or extending your current one. If you’d like to pass the code to a friend or colleague, that’s OK, too!

Roadmap: CLion 2020.2

Our main priorities for 2020 remain unchanged. Let’s see what particular enhancements we plan to implement during the next release cycle.

Please note: The following is only a preliminary plan. We cannot guarantee that all of the features listed below will be included in CLion 2020.2.
  • Language support and Clangd
    • Improve the stability of the Clangd-based language engine, investigate and fix memory leaks, and improve memory consumptions in general.
    • Enable Clangd-based code completion before indexing is complete.
    • Use Clangd-based engine for CLion’s Simplify inspection.
    • Continue fixing particular freezes in various areas.
    • Work on reducing CPU usage on projects like Eigen and others.
  • Project models
    • Continue with the Makefiles prototype (we hope to open it for public testing during this release cycle).
    • Support new features from CMake 3.16 and 3.17.
    • Allow disabling CMake profiles (CPP-12870).
  • Embedded
  • Debugger
    • Further improvements to the LLDB-based debugger on Windows for the Microsoft Visual C++ toolchain.
    • Ability to debug as root (CPP-7224).
    • Ability to debug with a core file (CPP-7977).
  • Unit testing
    • Update Boost.Test & Catch2 integration to support the latest enhancements in these frameworks.
  • Continue with various fixes in other subsystems, including Remote, Formatter, Code Coverage, Profiling, and more.

That’s it! If you have any new feature requests, please send them to our tracker. We’re listening!

Your CLion Team
JetBrains
The Drive to Develop

Comments below can no longer be edited.

39 Responses to What’s Next: A Roadmap for CLion 2020.2

  1. Taw says:

    April 30, 2020

    Thank you for the free license first of all.

    Secondly, are there any plans to improve the typing speeds when big macros are present?
    If one includes “curl.h”, even with Inspections set to off, there is a 2 second delay because curl has huge macros. Thanks.

    • Anastasia Kazakova says:

      May 1, 2020

      Yes, this was in plans for 2020.1, but was postponed till 2020.2. We are currently investigating possible options how to resolve it better.

  2. Ariel says:

    April 30, 2020

    It would be very nice to finally have Issue 68854 “Problems View Like eclipse” [ https://youtrack.jetbrains.com/issue/IDEA-68854 ] on the roadmap. It is already 9 years old, and has 300+ voters…

    • Ariel says:

      April 30, 2020

      It should be even an easy one! 🙂

    • Anastasia Kazakova says:

      May 1, 2020

      It’s actually planned for some release later this year in the IntelliJ Platform. However, it requires some thoughtful approach to UI/UX and requires some investigation in this direction. We are on it.

  3. Roman says:

    April 30, 2020

    I hope improvements for LLDB on Linux will also come, i.e. full support for libstdc++. On a large projects GDB is often unusable, with minutes of wait on startup. LLDB is better.

    Also, do you have any insights why debuggers on Windows are much faster?

    • Roman says:

      April 30, 2020

      >Enable Clangd-based code completion before indexing is complete.

      This won’t help until you allow creating and changing run configurations before indexing is complete. Ability to run application is much more important than code completion.

      • Anastasia Kazakova says:

        May 1, 2020

        These are two completely independent tasks. And seems different users have different requirements. However, the one you talk about is also under discussion now. Not that easy to implement, but is considered.

  4. Victor Sergienko says:

    May 2, 2020

    Thanks for bringing the proper attention to IDEA-232215. Sadly, it wasn’t enough and the freeze is still plaguing me.

    • Anastasia Kazakova says:

      May 4, 2020

      Sorry for keeping silence in the ticket. We are still investigating all the logs and dumps trying to get the source of the issue. It’s somewhere between VCS support and core CLion, but not yet clear. We are on it.

      • Victor Sergienko says:

        May 13, 2020

        I have ran VisualVM profiler on it, and have confirmed that the stack in the dump is the cause.
        I can run some tests locally, if you need.
        I’m desperate now, the whole blessed thing freezes for half an hour after a Perforce update. If there wasn’t Makefile support, I would be switching already.

        • Anastasia Kazakova says:

          May 13, 2020

          I suggested some workaround in the ticket to you, can you please give it a try?

          • Victor Sergienko says:

            May 14, 2020

            Yes!
            Thank you! Thank you! Thank you!
            It helped!
            After so much pain!
            Yaaay!

            • Anastasia Kazakova says:

              May 14, 2020

              Wow, happy to hear that! Thanks. Can you please also confirm in the ticket so that we link your report to the JBR problem?

  5. Richard Szabo says:

    May 2, 2020

    First I would like to thank you for Clion. It makes my life simple with embedded and multiplatform development.

    2nd:
    I’m sad to see that the remote development fixes are not getting prioritized (In my opinion the feature is broken, and not usable for a real-life project, due to the performance and reliability issues), :(.

    3rd:
    I’m really missing proper docker integration (not the workaround with ssh running in the container). Rather than Clion uses `mapped volumes` or maybe `docker copy`, and `docker exec` to perform configure/build/ debug/run steps.
    with the next release of windows (2020.04) and wsl2 docker containers becoming usable there as well.

    We are promoting it in our workflow:
    Since we are releasing docker containers with configured SDKs for cross-compiling to different targets (this way we are independent of the host environment and able to have a unified versioned development environment) we need an IDE which can integrate docker seamlessly in cross-platform hosts (Linux, Windows, OSX). My hope is that CLion could be the one. If the docker integration would have an acceptable perfomance,. We would even ship/promote Clion to our costumers.

    • Vasily Romanikhin says:

      May 4, 2020

      Thanks for your feedback.

      2. Unfortunately performance is the weakest part of remote development. We plan to continue work on it, in particular “Remote project file transfer is slow” (https://youtrack.jetbrains.com/issue/CPP-14365), “Slow CMake Loading” (https://youtrack.jetbrains.com/issue/CPP-14984).
      Also @Richard Szabo feel free share here the list of most painful issues for you.

      3. Docker support (https://youtrack.jetbrains.com/issue/CPP-13751)
      We are going to start work on docker support in coming release, but there is no estimates when we finish work.
      > I’m really missing proper docker integration (not the workaround with ssh running in the container).
      possibly in first versions we will still run processes via ssh, but we plan to eliminate unnecessary FS synchronization using mapped volumes.

      • Alexey says:

        May 17, 2020

        It sad to see that your roadmap contains a lot of features, while polishing them up (such as performance of remote development is not high on the list). These issues are in the tracker for years (e.g. very WI-1547similar issue in despite being marked major is open for almost a decade)

        As a result, there are a lot of features to promote but half of them are half-baked.

        I understand that of course you want attract new users with features and “remote development is finally usable” doesn’t sound like a selling point, but please do focus on finishing old features that will reduce the retention.
        I, for one, think I’ll not prolong my license anymore if remote development is not fixed when it expires next year

        PS: I noticed that you use localhost:2222 as a remote host in presentations such as AMA session you had recently, please consider developing with actual _remote_ hosts, may be you’ll fill the issues yourselves

        • Anastasia Kazakova says:

          May 18, 2020

          I’d like to say that it’s not true. Polishing current features is our top priority. We don’t share exact details in the Roadmap, but as you can learn from the AMA session there is a plan on improving performance for the Remote development (you can check the answer in the blog post https://blog.jetbrains.com/clion/2020/05/webinar-recording-clion-ama/). And we of course test it widely not only with the localhost address.

          • Andrew Grant says:

            June 6, 2020

            I would like to see remote debugging enabled for the Swift plugin. When can we expect to see that?

  6. Taw says:

    May 2, 2020

    Another question for me: are any plans to support multiple CMake projects in one CLion project? It’s not very important to me, just curious, it would be a nice addition in the future.

    So I can have multiple folders (A, B, C) in one CLion project/window, each with his own git
    repo and own CMake. The way that Visual Studio does with one .sln containing multiple .vcproj and you can right-click “set as default project”.

    Thanks

    • Anastasia Kazakova says:

      May 4, 2020

      We do have such plans, but I also have a question to you in this regard. What’s the user case for you? Do you need some cross features between these projects?

      • Taw says:

        May 4, 2020

        There are several use cases, I use all of them:
        1. We try to separate and modularize the repos as much as we can, in order to build faster.
        2. We have several “helper” libraries that all our project depend on, with their own CMake and repo.
        3. We ship shared libraries to our customers and we have several other projects (a daemon for example) which load and use these libraries.

      • Taw says:

        May 4, 2020

        4. We are designing a plugin system for our products and each plugin is in his own repo, but some high-level projects use all the plugins. At the moment I have usually 3-4 CLion instances open because of this, which take a lot of memory. It is not in my top-list, by my Eclipse friends asked me about this feature 🙂

        • Anastasia Kazakova says:

          May 6, 2020

          You definitely don’t need several instances, but at least can open several projects in different Windows.
          We do consider something similar to VS solutions support, but need to understand how related the projects inside solutions are and customize IDE actions to run either on a particular project or the whole solution.

          • Roman says:

            May 7, 2020

            Not sure how to use multiple windows today. It does not allow to launch debug session in one window, while build is active in another window (for different project). Says “Build in progress, sorry”. Do I need a second Clion license to work on two projects?

            • Anastasia Kazakova says:

              May 8, 2020

              This looks like a bug. It should be possible. Can you please submit to the tracker and we’ll proceed with some further investigation?

          • Roman says:

            May 8, 2020

            This is a variation of CPP-15077 . Even if rebuild is not necessary, Clion still need to launch ninja to make sure before launching lldb. But CPP-15077 requires a general solution. Imagine a situation: my work project builds 30 minutes, and meanwhile its building I want to work on hobby project. Clion won’t allow me to do so.

            • Anastasia Kazakova says:

              May 8, 2020

              You are right indeed. This is an old problem and seems we need to pay more attention to it.

  7. mumin16 says:

    May 9, 2020

    encoding problem in run tool window!

    -Dconsole.encoding=windows-1254 not work!

    https://imgur.com/JEu7md2

    • Anastasia Kazakova says:

      May 11, 2020

      Hi,

      Where exactly do you pass this console.encoding setting?

  8. Sebastian says:

    May 25, 2020

    Are there any plans to finally support the target_sources directive in CMake?

  9. HGH says:

    May 28, 2020

    “Performance, performance, performance”
    Stevie Balmer

    • Anastasia Kazakova says:

      May 28, 2020

      For sure, that’s our main focus.

  10. HGH says:

    May 28, 2020

    On Android getting out of JNI function iins C++ back into kotlin requires many clicks (step out). Is that somehow related to Clion?
    Would it be possible to skip the boilerplate code, system/library headers etc. abd debug just my code as Visual Studio introduced for MSVC a while ago?

    • Anastasia Kazakova says:

      May 28, 2020

      Do you mean in Android Studio or CLion?

  11. Stephane says:

    June 3, 2020

    Since you are looking into rejuvenating CMake support in this release, it might be a good time to look into adding target_sources directive (https://youtrack.jetbrains.com/issue/CPP-9942). Clion is currently oblivious to this syntax.

    • Anastasia Kazakova says:

      June 4, 2020

      This is a good idea indeed. However, don’t think we’ll be able to include it into the v2020.2 as there are many other important tasks with higher priority. But definitely an interesting request to consider for the future.

Subscribe

Subscribe for updates