What’s Next? CLion 2019.3 Roadmap

Posted on by Anastasia Kazakova

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

JetBrains
The Drive to Develop

Comments below can no longer be edited.

45 Responses to What’s Next? CLion 2019.3 Roadmap

  1. Olof says:

    August 5, 2019

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

    This is great!

    • Anton says:

      August 5, 2019

      I totally agree and appreciate it a lot! Thank you guys for listening to us.

    • Martin says:

      August 15, 2019

      I completely agree with this!

  2. Roman Popov says:

    August 5, 2019

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

  3. Olof says:

    August 5, 2019

    > 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:

      August 5, 2019

      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:

        August 5, 2019

        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
        iGO//
        G
        o//
        //
        :r something.cpp
        i//
        1G

        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:

          August 5, 2019

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

          editor-fold desc=”Description”
          /editor-fold

        • Anastasia Kazakova says:

          August 5, 2019

          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:

            August 5, 2019

            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:

            August 5, 2019

            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:

    August 5, 2019

    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:

      August 5, 2019

      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:

        August 5, 2019

        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:

          August 5, 2019

          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:

            August 8, 2019

            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:

              August 8, 2019

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

          • Taw says:

            August 8, 2019

            Cannot show*

  5. TheLordofdirTB says:

    August 5, 2019

    result from try_emplace of map still not auto complete

    • Anastasia Kazakova says:

      August 5, 2019

      What platform/compiler are you using?

      • TheLordofdirTB says:

        August 5, 2019

        Visual Studio 2019 Community

  6. Helge Penne says:

    August 6, 2019

    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.

    Examples:
    CPP-1474
    CPP-1475
    CPP-4181
    CPP-5501
    CPP-6195
    CPP-8387
    There are also lots of related bus referenced from CPP-2 (!)

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

    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:
    CPP-9623

    • Anastasia Kazakova says:

      August 6, 2019

      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:

        August 6, 2019

        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:

    August 7, 2019

    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.

    • Helge Penne says:

      August 7, 2019

      That would be much appreciated. So far LLDB in CLion (at least on Linus) does not show the values of STL types in a proper way. Everyone please upwote:
      https://youtrack.jetbrains.com/issue/CPP-6717

      Not being able to see STL container values is ridiculous in this day and age. Please fix this. This is absolutely basic functionality that everyone expects to simply work.

      • Helge Penne says:

        August 7, 2019

        On second thought, it’s better to upvote this one as it has more votes already:
        https://youtrack.jetbrains.com/issue/CPP-6671

        • Anastasia Kazakova says:

          August 7, 2019

          Yes, that’s what we were considering among others in the debugger subsystem. Thank you.

      • Zach says:

        August 10, 2019

        There is a workaround on macOS – not sure if it works in Linux. The workaround is to disable CLion’s pretty formatters. Here are some instructions:
        https://youtrack.jetbrains.com/issue/CPP-14918#focus=streamItem-27-3224912.0-0

        Perhaps the issue can be finally fixed by disabling these formatters by default? Not sure if they provide any benefit and lldb’s api often changes.

  8. Henry says:

    August 8, 2019

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

    • Anastasia Kazakova says:

      August 8, 2019

      Hope we can deliver all of these in 2019.3

  9. Andrew Marshall says:

    August 14, 2019

    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.

    • Anastasia Kazakova says:

      August 14, 2019

      Do you mean 2019.2? Could you please specify which exactly performance issues do you have?

  10. Jiawen Geng says:

    August 15, 2019

    When we can try 2019.3 ?

    • Anastasia Kazakova says:

      August 15, 2019

      The EAP will start in approx mid September

  11. Thomas Johnson says:

    August 22, 2019

    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:

      August 22, 2019

      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:

    August 26, 2019

    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.

    • Anastasia Kazakova says:

      August 30, 2019

      We’ll definitely consider that. Stay tuned.

  13. David Rees says:

    August 27, 2019

    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:
    https://youtrack.jetbrains.com/issue/OC-11216

    • Anastasia Kazakova says:

      August 30, 2019

      Thanks David. We’ll definitely consider that.

  14. Andrew Smith says:

    September 9, 2019

    “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:

      September 9, 2019

      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:

    September 20, 2019

    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.

Subscribe

Subscribe for updates