Our Plan for Next Year and the 2020.1 Roadmap

This year’s third big update – CLion 2019.3 – has landed, along with its first bug-fix update, 2019.3.1. If you haven’t yet updated your CLion, now is a great time to do so.

Before moving forward on to 2020, we’d like to give our most sincere thanks to our Early Access Program users! Without you we wouldn’t be able to catch so many annoying issues affecting the wide variety of C++ environments, and make CLion as good as it can be!

Special thanks

We’d like to present our most active EAP evaluators with a full 1-year subscription to CLion, which they can use to buy a new subscription or extend a current one. Feel free to pass the code to a friend or colleague! So our special thanks go to:

  • Roman Popov
  • Maxim Yanchenko
  • Miha Rozina
  • Roland Illig

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 2020

Let’s first look at the main priorities we have for 2020. Actually, they haven’t changed much since 2019. We are still focusing on:

  1. Performance and responsiveness: continue eliminating UI freezes and working on large architectural changes to make global improvements to CLion’s performance.
  2. Clangd: make the engine more stable and eliminate crashes, move as many IDE functions as possible to Clangd, and add new language features on top of the Clangd-based language engine.
  3. Project model: work on native support for Makefiles, consider other build systems such as Bazel, and work towards a project model API in CLion.
  4. Embedded: double the efforts we put into the embedded development support and work on more essential features in this area.

Taking on 2020.1

Here are the main tasks we’ve set for the next release, CLion 2020.1, which should be out around late March.

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.1.
  • Clangd-based engine:

    • Improve engine stability, eliminate crashes, investigate memory usage.
    • Fix Clangd code completion issues.
    • Automatically use the .clang-tidy config file in the project directory, if any.
    • Move Data Flow Analysis to Clangd to improve the performance.
  • C++ support:
    • Initial CUDA support.
    • Enhance typing in the multiline macros, and add other performance and responsiveness improvements.
    • Introduce default values for Change Signature refactoring.
  • Project Models:
    • Native Makefiles support.
    • Polish the CMake File API integration (including recompiling a single file).
  • Debugger:
  • Embedded development:
    • IAR and armcc toolchain support (CPP-14192).
  • Various fixes and enhancements:
    • Fix bugs and freezes related to remote toolchains.
    • Automatically add required compilation flags for sanitizers/coverage.

This is what’s going to keep us busy. If you have any new feature requests, please 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.

47 Responses to Our Plan for Next Year and the 2020.1 Roadmap

  1. Taw says:

    The plan looks really good, especially “Enhance typing in the multiline macros, and add other performance and responsiveness improvements”
    The typing lag is one of the most severe problems of CLion, for example when one includes cURL headers.

  2. Roman Popov says:

    >Polish the CMake File API integration (including recompiling a single file).
    Please also fix CPP-18238. I can’t share source code, but I can provide you any logs you need.

  3. Florian says:

    This roadmap really looks promissing:
    * performance improvements related to macros might make our big C project finally usable with CLion.
    * Fixing default values after Change Signature refactoring was annoying.
    * Getting back recompiling a single file with ninja generator would be awesome. I love this simple but really convenient feature.

  4. Taw says:

    Anastasia, what are the plans for the debugger? It has some ugly bugs, like not able to show properly char arrays

    • Anastasia Kazakova says:

      We are constantly working on pretty printers issues. Can you please point to a particular issue in the tracker?

      • Taw says:

        Thanks, the most important is CPP-12739.
        But there are some other small ones like CPP-13954, CPP-13262, CPP-13448, IDEA-195289, IDEA-195290 (is this very hard to fix? is just remembering an option)

      • Romain says:

        Is there any plan making custom pretty printers available? For example, when using the EASTL which we do at work, it would be great to be able to see data more easily!

        • Anastasia Kazakova says:

          What’s the problem if using them right now? Just pass via .gdbinit/.lldbinit (either the one in your home directory or inside the project directory).

  5. Nestal says:

    Makefile support is very important. Thanks for including it. Will keep voting with my wallet.

  6. Philip says:

    Can you say something more about the embedded support, are we going to see some Arduino support, and do you plan to have something like the cube IDE configurator in the future?

  7. Taw says:

    Not related to the roadmap, but what was the reason to rename “git revert” to “git rollback”.? (I think it was done in 2019.1 or 2019.2).

    In almost all git documentation the “revert” word is used, not “rollback”.
    It is not very intuitive, thanks.

  8. KB says:

    I would love to see Bazel work immediately as of every new release! Right now one must wait for Google to update their plugin.

    • Anastasia Kazakova says:

      We plan to collaborate with Google and see what we can do in order to improve it. Unfortunately, the main issue is that project model API is very unstable in CLion now, so no surprise Google has to update the plugin constantly, this causes delays.

  9. Cocal says:

    is it planned to have LLDB as a WSL debugger?
    I have issue with libc++ pretty print.

  10. MB says:

    Please do not delay input redirection any more.

  11. Coval says:

    Any plan to have remote LLDB or WSL LLDB?

    Support for clang for Windows would be great also.

  12. Roman Popov says:

    What is the best way to deal with monorepos in Clion? I.e. when all company projects stored in same git repo / root directory, with cmake -DPROJECT=XYZ selecting the project to build.

    So far I was creating multiple build configurations, that allowed me to switch quickly between projects. But size of codebase quickly increases and Clion becomes slower and slower. So I’m thinking of options:
    – Can I create multiple Clion projects in same directory?
    – Can I have an option in Clion to build index only for currently active build configuration (and rebuild it only when I switch projects)?

    • Dmitry Kozhevnikov says:

      Hi Roman,

      a somewhat inconvenient workaround would be:

      1. Open some dir inside a project (even if it doesn’t contain CMakeLists.txt)
      2. Execute “Tools | CMake | Change Project Root” action and point to the root of the monorepo
      3. Set up CMake from there (you might have to right-click on the root CMakeLists.txt -> Load CMake project if ti doesn’t load automatically)

      This way, you can have multiple projects opened this way separately, each of them should have C/C++-specific indicies only for the selected project and it’s dependencies (the rest of the project tree would be indexed just for text search , etc).

      Does it help?

      • Roman Popov says:

        Thanks! Much better now, I wish I had asked earlier. Will work using this methodology going forward, switching projects using File->Open Recent, instead of switching build configurations… Let’s see how it will work, but opening project is noticeably faster now.

        One note: If I open empty sub-directory as project “Tools | Cmake” is not active. So I had to create an empty CMakeLists in this directory, to be able to change root. And then remove this empty CMakeLists

      • Roman Popov says:

        Wow! It also solves CPP-18238. I.e. if I have multiple projects, instead of multiple build configurations, I no longer need to rerun CMake after each IDE restart.

      • Roman Popov says:

        Wow, also solves IDEA-228567 ! Commit window is usable again

  13. Eicke Herbertz says:

    Any plans on support for CMakeSettings.json or something similar (CPP-7911)?

    • Anastasia Kazakova says:

      Could you please share your use case and which settings you’d like to share via VCS. Thanks

      • Eicke Herbertz says:

        The “Build, Execution, Deployment > CMake” settings. Basically, the CMake command line.

        We are developing projects targeting multiple embedded systems and depend on CMAKE_TOOLCHAIN_FILEs and several other command line settings. Every developer pasting them manually is tedious and error-prone.

        Also, I’d still like to see direct support for CMakeSettings.json.

  14. Asys says:

    Does that mean you currently still don’t have any plans for native meson support, or is that also targeted for somewhere in the 2020 release cycle?

  15. Gladilov, Gleb says:

    Hi CLion Team! Thanks for your job, your product is the best for C++ development right now (IMHO of course). I have a question regarding some feature. Let’s say I want to disable auto CMake reloading on external changes (AFAIK disabling button auto reload CMake does not work here). Is it possible to do? Is there a chance it would be scheduled in coming releases?

    • Anastasia Kazakova says:

      Not possible now and no plan to do so. But feel free to create a request in the tracker and explain your use case for us to consider it.

  16. Roman Popov says:

    Any chance to get CPP-7361 fixed in 2020? 3-year old bug, and very annoying.

  17. Vladislav says:

    Are there any plans for memory view improvements? e. g. make it resizable, provide choice of word lengths etc, like in Eclipse CDT

Leave a Reply

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