What’s Next? CLion 2019.3 Roadmap

CLion 2019.2 landed just a few days ago. Do check it out if you haven’t yet! It’s got a lot of cool things for Embedded developers, an experimental debugger for the MSVC toolchain, a more flexible and reliable Unused Includes check, parameter code hints, and much more. Here is a fantastic video from Phil Nash to quickly take you through the key highlights.

Meanwhile, we are moving forward and thinking through our future updates and the next release. But before we share our plans, let’s take a minute to give our sincerest thanks to the most active evaluators, who helped us make v2019.2 more stable and accurate.

Special thanks

We want to thank all the users – more than 4 thousand in total! – who participated in the 2019.2 Early Access Program. You helped us immensely with the huge variety of possible setups and configurations, and even a few general issues we somehow missed. We greatly appreciate your help!

Continuing our ongoing tradition, we present our most active EAP evaluators with a full 1-year subscription to CLion, which can be redeemed as a new subscription or an extension of a current one. So, here are the contributors that we want to give special thanks:

  • Dmytro Nezhevenko
  • Ivan Stepanov
  • Patrick Turley

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.3 roadmap

We take application performance and code quality very seriously. Following the internal performance week / hackathon that our team held together with the IntelliJ Platform team this June, we are now planning a special Quality-targeted Release. Here’s what that means in simple words:

  1. We’ll work to flesh out and implement the fresh ideas and fixes we tried during our performance hackathon.
  2. We plan to work intensively on various performance boosts, including some massive overhauls we started earlier this year. You can expect a series of blog posts covering the progress and explaining the underlying ideas, with some measurements on referenced projects so that you can compare them with your cases.
  3. We plan to focus on fixing issues and eliminating pain-points in different areas, rather than introducing new functionality. (Don’t forget to upvote the pain-points that affect you the most, so that we can prioritize them to help as many users as possible!)
  4. We still plan to continue our work in the directions we feel are important, such as covering Makefiles support and some others. Please read on for the details.

The following is a detailed plan for the next release cycle.

Note: This is a preliminary plan, which means we cannot guarantee that all of the features listed below will be included in CLion 2019.3.
  • C++ language support

    • Mostly bug-fixing and performance improvements as mentioned above.
    • Rework an action to switch header/source (CPP-12920).
    • Deeper integration with the Clangd-based engine, especially in the areas where it helps eliminate performance issues and lags (for example, Clangd-based code completion).
    • Investigation and fixes for various crashes and memory leaks in Clangd-based engine.
  • Project model
  • Remote development
    • Investigate WSL v2 support opportunities (CPP-16543).
    • Remote debugging with gdbserver via ssh (CPP-7050).
    • Performance improvements for remote mode.
  • Debugger
    • Improve the quality of the experimental debugger for Microsoft Visual C++ toolchain (you can expect some NatVis related fixes in 2019.2.x updates already).
    • Support for .gdbinit/.lldbinit located in project folders.
    • Input/output redirection (CPP-3153).
    • Performance investigations and improvements.
  • Embedded Development
    • Mostly bug-fixing (which means your feedback on the recently added functionality will be very important!).
    • Console for GDBServer (CPP-15392, CPP-7103).
  • Code coverage

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

45 Responses to What’s Next? CLion 2019.3 Roadmap

  1. Olof says:

    > We plan to focus on fixing issues and eliminating pain-points in different areas, rather than introducing new functionality.

    This is great!

  2. Roman Popov says:

    Totally aligns with my most wanted features: performance improvements, bugfixes, ninja, windows debugging.

  3. Olof says:

    > Rework an action to switch header/source (CPP-12920).

    How about a solution that displays cpp files and its header file in one document?

    Like, with the header file at the top and if you scroll down you seamlessly (with a tiny separation line) move into the cpp file?

    This would encourage code that compiles faster with more code in the cpp file while still having most of the code productivity benefits of coding in header files.

    We code mostly in header files because of the code productivity improvements but if you change the wrong header file it’s coffee time.

    I hope this would be a fairly simple solution as it is purely a cosmetic one and the complexity should be local to the GUI.

    • Anastasia Kazakova says:

      You can now open both in the split editor (you can split vertically or horizontally from the context menu on a tab).
      Regarding automatic open for header/source in the editor, it’s not that simple change. In the past we were considering smth similar to Xcode’s assistant editor (https://youtrack.jetbrains.com/issue/OC-2581) but haven’t decided anything about it yet.

      • Olof says:

        That thing, but with one scroll bar.

        I don’t know the complexities that would happen in your particular environment. How about markup similar to git? Both files would be put in the same document window and then a hidden >>>>>> or some magic character sequence or something using the #region functionality and it would be the demarcation and represented as that line.

        Maybe it can use existing folding functionality


        I’m thinking maybe this could even be done with a plugin.

        Using the vim just to illustrate how the files could be loaded.

        :e something.h
        :r something.cpp

        And then there needs to be a way to store them with their original names.
        The newly created and concatenated file should itself never be stored.

        That isn’t an elegant solution but it would be simple and the effect would be large. It would fundamentally change how many people develop C++.

        There’s ways to make this more elegant. This is an illustration.

        • Olof says:

          Oops, the folding commands got removed, but I was using:

          editor-fold desc=”Description”

        • Anastasia Kazakova says:

          Ok, but why splitting the editor doesn’t work for you? What are the use cases when you need header and source to be open automatically in two tabs? And finally, in C++ world, how to deal with indirect matches, I mean we are not in a Java world when a header and source files go in pairs, but there might be some general header and several sources and other configurations. Would be good if you can address these cases in the tracker, describing exactly what you need and how you’d like to use it. Thanks in advance!

          • Olof says:

            The most important header file for a .cpp file is the one specifically advertising the public interface of whats in that .cpp file. The something.cpp and its something.h.

            All other header files are secondary. I don’t mind ctrl-clicking to go to them.

            The reason we program in header files is simply because it is more convenient. So it makes the developer more productive but it makes compiling slower, which also affects the developers productivity because of the slower feedback loop.

            So we want to eat the cake and have it too. We want to luxury of dealing with only one file for a class, like Java programmers can but we want recompiling to be fast.

            If we could see both files in one open document window, and be able to scroll around quickly between the interface (.h) and the implementation (.cpp) then it would be far less cumbersome to split a class up in a header file and a .cpp file.

            Now, the ideal would be something more complicated And that would be to code entirely in a .h file and have it get split into a .h and .cpp file automatically without the developer even seeing those files. But that requires parsing C++ to extract the interface to put that in the header file and convert the rest to the implementation of that interface.

          • Olof says:

            Oh, why the split doesn’t work. The key is that windows are independent of each other. So keeping my bearings is the crux. I don’t want twice the tabs and twice the smaller windows.

  4. Tano says:

    This is great news, thanks!
    I was wondering what about old small issues that should be easy to fix? For example IDEA-195290 or IDEA-195289?
    Of course there are a lot of them out there.

    • Anastasia Kazakova says:

      Thank you. I can’t promise you anything in particular. We’ll consider all the issues across all the subsystems, along with the platform team. We’ll definitely won’t be able to fix all of them during one release cycle, but we’ll try to select those affecting the most users.

      • Tano says:

        I perfectly agree that the most voted should be fixed first, but if there are trivial ones, I think that should be fixed also.

        • Anastasia Kazakova says:

          yes, but there are quite many of those. And we definitely need some order, which means prioritization. Thanks for pinging us with that tickets.

          • Taw says:

            I know, but I guess some of them are easy to fix, maybe a few hours. And some are really regressions, like PY-32404.
            Also 2 years old problem: IDEA-172063

            It’s a pity that such a great IDE like CLion cannot search a file’s extension when searching…

          • Anastasia Kazakova says:

            This IDEA ticket will also be considered for a fix during the next cycle. Thanks, Taw.

          • Taw says:

            Cannot show*

  5. TheLordofdirTB says:

    result from try_emplace of map still not auto complete

  6. Helge Penne says:

    This is great news. Please please please fix the issues related to automatic insertion og include statements (there are lots of open bugs for this). It should be configurable to use either “” or , and it should at least be possible to configure CLion to not add includes automatically/silently. As it is now, it sometimes pollutes the code with includes without the programmers intent or knowledge.

    There are also lots of related bus referenced from CPP-2 (!)

    And please also support post mortem debugging. “All” other IDEs do:

    And if I could wish for one more thing, please fix the broken Ctrl-Shift-F6 refactoring when using Doxygen comments. This is just the type of lack of attention to quality on your part that drives programmers crazy and has seriously annoyed your customers the last years. Dismissing this as “not a priority” is not acceptable. If you can’t be bothered to make it work properly then you should never have released Doxygen support in the first place. When it is broken like this then it’s worse than no Doxygen support at all:

    • Anastasia Kazakova says:

      Thank you, Helge.

      I agree auto-import issues are rather annoying. Hopefully, the general parser work and clangd migration will help us eliminate those.

      As for the core dumps debugger, indeed, we want it very much. The team itself misses it while developing Clangd in CLion) However, it still goes after debugger-related issues, which have to be fixed first anyway.

      And for the CPP-9623, I disagree that current Doxygen support is not usable at all w/o it. While I do agree this one is important. We’ll consider it. Thanks

      • Helge Penne says:

        I’m glad that you find it important and will consider it. I cannot ask for more than that. Thanks. I really appreciate the current focus on quality, performance and bug fixes. It has already improved a lot over the last couple of releases.

  7. Roman Popov says:

    Do you plan to work on better LLDB support on Linux? Because honestly GDB is just so terribly slow, so I would be happy if I can use LLDB on all platforms.

  8. Henry says:

    oh man! This seems like an exciting roadmap.
    * CMake File API (CMake server promised so much but delivered not much more than a headache)
    * Ninja!
    *Code Coverage!!

  9. Andrew Marshall says:

    Looking forward to seeing the performance imrpovements in 2019.3. I know everyone has their own particular bugbears, but for me this has to be top priority as, sadly, the current version is virtually unusable on Linux.

  10. Jiawen Geng says:

    When we can try 2019.3 ?

  11. Thomas Johnson says:

    Is there any hope for native Bazel support in CLion? The bazel plugin consistently lags behind the Jetbrains CLion releases and has serious C++ bugs that have been open for months

    • Anastasia Kazakova says:

      Bazel plugin is maintained by Google team. And for now, we don’t have plans to reimplement the support. But with more stable project model API (upcoming), it might become easier for Google to maintain the plugin.

  12. Jonathan Ross says:

    Does the deeper integration with the clangd engine also include upgrading to clangd 10? There are some improvements in clang-format that I’d love to be able to use.

  13. David Rees says:

    Regarding discussion about header/source. I think there are several related items that CLion could do to really help with working across header/source:

    Have the structure view show the all the member info for source files (https://youtrack.jetbrains.com/issue/CPP-1703). That way someone in source file can see relevant info in structure view.

    Add annotations in source view to show the header information (private, etc).

    And getting hierarchy view working would help with a lot of common reasons users jump through header:

  14. Andrew Smith says:

    “Remote debugging with gdbserver via ssh”

    Will the above feature work for non-remote projects that do not use CLion for building? I currently use CLion to author code for a project that is built with an unsupported build system. I want to be able to debug binaries remotely using ssh. I can already do so via gdbserver, but this requires transferring gigabytes of symbols each time which is extremely slow.

    • Anastasia Kazakova says:

      This is exactly the case. You can now start a gdbserver on a remote machine and then connect from CLion using the Remote GDB Server configuration. However, the idea is to automate the flow to avoid the step with manually connecting to the remote host, starting the gdbserver over there, etc.

      When we implement the feature, we’ll check if there are any limitations for how the project is built.

      BTW, for the unsupported build system, you can use Custom Build targets to build/clean from CLion using custom commands: https://www.jetbrains.com/help/clion/custom-build-targets.html

  15. David Rees says:

    Note for others, “Copy Relative Path” has been renamed to “Copy Reference”. That seems to be a general pattern across 2019.3 that now you choose “Copy Reference” and then what reference you want.

Leave a Reply

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