Moving into 2019. CLion roadmap

This year’s third big update – CLion 2018.3 – has landed just a few days ago! It’s all about Remote Development, CPU profiling, and better C++ language support.

Following our good tradition, we want to thank those evaluators who have helped us ship so many goodies and still keep the release stable. Our special thanks go to:

  • Oliver Stöneberg
  • Michael Klatt
  • Dmytro Nezhevenko

In appreciation of your efforts, we are giving each of you a free 1-year subscription for CLion (to extend your current subscription or get a new one). 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 2019

Our main areas of focus for next year:

  1. Boost performance & eliminate freezes
  2. Wider integration with Clangd-based language engine
  3. Embedded development support

These 3 areas will occupy most of our time and resources and will entail hundreds of various tasks. For example, Embedded development is a huge and diverse area, and our first step will be into the STM32 family of boards. At the same time, it will require lots of changes and improvements in debugger support, project models, and so on. Even if you don’t do Embedded development, you may still benefit from CLion taking this path.

Plan for CLion 2019.1

Note: The following is a preliminary plan; we cannot guarantee that all of the features listed below will be included in CLion 2019.1.
  • Embedded Development

  • Debugger
    • Rework experimental hex implementation
    • Add memory view to CLion
    • Add disassembler view for LLDB debugger (only available for GDB for now)
    • Work on debugger for MSVC on Windows (this might not be finished by the time 2019.1 is released, but some experimental preview will likely be available)
  • C++ support
    • Better indicators related to the Clangd-based engine (in order to measure the memory and CPU usage for this new engine on the user’s side)
    • Wider integration with Clangd-based language engine: the next candidate is syntax highlighting
    • Various bug-fixes in CLion’s own language engine
  • Performance improvements and elimination of freezes: here we plan to focus on memory and CPU usage, investigate deeper first project indexing times and completion performance.
  • Formatter: Clang-format integration
    • In reformat action
    • On the commit stage
    • Automatic Clang-format config detection
  • Project models: continue detaching the API

That’s it! Do you have any new feature requests? Send them to our tracker. We’re listening!

Your CLion Team

JetBrains
The Drive to Develop

This entry was posted in Announcement and tagged , , , . Bookmark the permalink.

32 Responses to Moving into 2019. CLion roadmap

  1. Tano says:

    The roadmap looks really nice, but I want to point 2 things:

    1. Please watch out for clangd, sometimes it misbehaves badly, for example I opened CPP-14739 in which it works the reverse way, meaning that the “-Wno-missing-field-initializers” is set, but it shows the warning. When I delete that line (so the warning should be shown), it does not show the warning anymore.

    2. I also talked with Eldar about this, my general feeling is that the debugger in CLion is not evolving in any way, although CLion has a lot of other features added in every version. And the debugger is one of the most used things in an IDE. It’s nice that you add memory view.

    Also here are some bugs easier to fix, because they are only related to GUI: CPP-13954 IDEA-195290 IDEA-195289

    Thanks.

    • Anastasia Kazakova says:

      Clangd work will be definitely continued, that’s part of this roadmap. And we commented on the source of the problem in https://youtrack.jetbrains.com/issue/CPP-14739#focus=streamItem-27-3195351-0-0

      Regarding the debugger, this might be not that visible outside, from the user’s perspective, but there is a huge work on improving general debugger experience, output handling, performance improvements, updating bundled debugger versions and fixing dozens of compatibility issues. Mem view was also started during this iteration but turned out to be harder than we expected it to be, so will be continued in 19.1.

      And the UI issues are not always just UI, but some other behaviour which might affect performance, etc. But we’ll take a look when have some free time.

      • Tano says:

        Yeah, thanks, your colleague tells me to add that option but it is very clear that I have it already (I provided a compiler options .txt) 😀

        I perfectly understand the performance penalties for the debugger, but it is not always the case, for example IDEA-195290 should be fixed in a few hours.

        Thanks Anastasia

      • Tano says:

        Hi again, I kindly ask you (or another colleague, besides Maxim, because he is telling me the same thing from the couple of days) to take a look on CPP-14739 when someone has a little time please, there are 2 problems there:

        1. Maxim told me that the problem is caused by the fact that I have “-Wextra” in my CMake file, why is the static analyzer reading my CMake?

        2. In the CMake also later I have “-Wno-missing-field-initializers” later in the CMake, so it should work. I also deleted “-Wextra” from the CMake and still it does not work.

        3. I set in clangd option “-Wno-missing-field-initializers”, meaning DO NOT show the warning and it seems to show it. Then I delete that line (the warning should be shown now) and …gues what…the warning is not shown. So it works in the reverse way.

        Thanks.

  2. Rogiel says:

    “Better indicators related to the Clangd-based engine (in order to measure the memory and CPU usage for this new engine on the user’s side)”

    One issue I have been having with the clangd (and with clang-tidy if clangd engine is disabled) is a very weird bug in clang. Sometimes template evaluation recurses indefinitely and memory explodes (to the order of 30-40GB — Darwin is able to compress most of it though) and I need to kill clangd executable manually.

    I know this is not CLion related, but would be nice if CLion could keep track of its children processes and kill them if anything goes out of control like that.

    • Anastasia Kazakova says:

      Definitely! And this task you’ve mentioned is exactly dedicated to the situations like that you described.

  3. Mike says:

    Please consider CPP-2659. A single Windows nmake build takes *minutes*, Ninja takes less than a second. At this point, I have a DOS window open that runs the cmake ninja build from the command line rather than building within CLion. That works just fine–it keeps the IDE happy and allows me a quick build.

    I understand you have issues in how to import build information and that Ninja Codeblocks isn’t the same as Nmake Codeblocks. Perhaps a parallel build?

    This one is huge for me–a minute+ to build is a massive slowdown and morale killer.

    Thanks for listening!

  4. Fabian says:

    Any chance to get disassembly of code where you have the source code? This often helps debugging what one wrote in C++ and what it turned out in assembler. See https://youtrack.jetbrains.com/issue/CPP-9091

  5. Henry Borchers says:

    Holy smokes!! You guys are finally working on a MSVC debugger support?!?! This will make my Python+C work on Windows so much easier. I love you guys!

  6. johnthagen says:

    With the STM32 integration work, are there any plans to also support Rust? https://github.com/intellij-rust/intellij-rust/issues/2748

  7. johnthagen says:

    Any chance there would be time to support coloring parameter names in Doxygen comments? It would really help the readability of inline docs in all C/C++ projects.

    https://youtrack.jetbrains.com/issue/CPP-10311

    Thanks.

  8. johnthagen says:

    Would it be possible to bundle the Markdown plugin like is currently done for PyCharm? Markdown is very ubiquitous now and it’s really convenient when it’s bundled since the Markdown plugin usually only supports a narrow slice of IntelliJ/CLion versions.

    https://youtrack.jetbrains.com/issue/CPP-7520

  9. Roman says:

    For embedded you should probably seek collaboration with platformio.org or mbed.com to enable Clion as alternative IDE.

    • Anastasia Kazakova says:

      We’ve chatted with Platform.io in the past. They have a CLion dedicated layout and generate CMake compatible with CLion. They do not promote any particular IDE, but CLion is already mentioned on their site and works nicely.

  10. Helge Penne says:

    This seems like a great roadmap. The 2018.3 release seems like a good step in the right direction with regards to freezes and performance, but there is still some way to go. It’s good to see that this is a priority.

    Is there any chance that you will be able to fix this annoying bug in your refactoring functionality? Refactoring is supposed to be your strength, but this bug ruin important parts of it for those who comment their code:
    https://youtrack.jetbrains.com/issue/CPP-9623

    You also have some but silly and annoying problems with something as basic as #include statements:
    https://youtrack.jetbrains.com/issue/CPP-1475
    https://youtrack.jetbrains.com/issue/CPP-1474
    https://youtrack.jetbrains.com/issue/CPP-5501
    https://youtrack.jetbrains.com/issue/CPP-4181
    (there are many more duplicate reports of the same problem).

    Those really need to be fixed. Can you please get these prioritized?

    Then there is some important debug functionality that lots of users really want:
    https://youtrack.jetbrains.com/issue/CPP-7224
    https://youtrack.jetbrains.com/issue/CPP-7977

    Finally, it would be great to be able to turn off the editor warnings/errors from CLions parser completely, and only show the warnings from clang tidy. I’m sorry to say that the CLion parser has too many false positives, and many of them cannot be turned off in the inspection settings. The many false positives from CLion’s parser makes the clang positives less useful, so we would appreciate the ability to turn of the highlighting from CLion’s parser completely. That is currently not possible. This should be very simple to do, I think.

    • Anastasia Kazakova says:

      Thank you for your positive feedback.

      https://youtrack.jetbrains.com/issue/CPP-9623 – is indeed unpleasant, but seems more like a missing feature. We hope to address if when have some free resources for that.

      Autoimport / includes related fixes are currently postponed for a while, we hope to reimplement that part of this functionality with Clangd help.

      Debugger issues will come sometime after the list mentioned in the roadmap, as it’s more important from our perspective.

      Regarding warning and errors, they are now taken from Clangd by default (have you turned it off?)

      • Helge Penne says:

        I have turned off “Show warnings and errors from clangd” in Settings, if that is what you are referring to. I have also turned off everything in Settings/Editor/Inspections except clang tidy, but I still get lots of warnings and error annotations from some other source than clang tidy. Why do you have annotations that can’t be turned off?

        One warning I’m looking at right now is an “err_typecheck_call_too_many_args”. This code is correct and compiles just fine so this is a false positive, and I have so far not found any way to turn this off except let CLion insert “#pragma ide” lines (which is unacceptable). There is also an “err_ovl_no_viable_member_function_in_call”. As far as I can tell, these are from clangd, but I have turned off warnings and errors from clangd in settings. Is that broken? It also does not seem to make any sense at all that clangd outputs warnings for code that compiles just fine with clang.

        If I could turn off all sources except clang tidy then I could let CLion perform code analysis on commit, but all the false positives makes this impossible.

        This seems to be broken and needs a fix. Should I file a bug report for this? I have assumed that you have lots of bug reports already on warning/error highlights in the editor, because this has never been very reliable in CLion.

        • Anastasia Kazakova says:

          > I have turned off “Show warnings and errors from clangd” in Settings, if that is what you are referring to.
          Exactly. I really recommend you to turn it back on, it’s an accurate errors from clangd-based engine. If you see any false positives, please report them.

          PLease, file bugs about false positives.

  11. TheLordofdirTB says:

    please full support autocomplete C++17 like “auto result = map.try_emplace”

  12. Alexey says:

    There are some things which lacks in CLion, and some which lacks in other Intellij products also.

    First, it would be good to have a kind of integration for pretty-printers.
    CLion already supports python editing and gdb debugging. So, what about to combine them and give possibility to view and debug python pretty-printers for gdb? (yes, it is possible now to edit them, but as absolutely separate python source aside, agnostic to the fact that this very code will be run by this very gdb in this very IDE next moment).

    Second, more detailed support for viewing diffs/commiting to vcs.
    Now it is possible only to select/deselect a chunk or even bunch of chunks for partial commit. If I’ve added two lines of text, I have no choice to commit only one of them and leave second alone. That is the reason why I still use ‘git gui’ – since there I can not only ‘add block to the index’ (the same thing which clion do when I check a box near a patch), but also ‘add line to the index’ – which allow to split patches/blocks into separate lines.

    • Anastasia Kazakova says:

      Not sure I got the problem with pretty-printers. You can edit them and substitute .gbtinit/.lldbinit in your home directory and CLion will take them.

      Regarding the second one, indeed, this might be very useful. Can you please submit a report to IDEA tracker?

  13. Andrew says:

    CLion 2018.3 had “initial remote development support.” Remote development isn’t listed on the 2019 roadmap. Does that mean future work on the remote development experience will not happen in 2019?

    In particular, might the gdbserver-less debugging (over ssh) be extended to already-built (and/or already-running) binaries on the remote host? Right now, you have to have CLion build the project and start the debugging process for this to work, which means it is not usable for projects CLion can’t build itself (and that are instead built by an external system). While gdbserver could in theory be used, transferring gigabytes of symbols on every debugger run is not feasible.

    It seems like you have almost all the hard work there already to support gdbserver-less debugging; all that is missing is a UI entrypoint.

    • Anastasia Kazakova says:

      We treat remote as part of the huge embedded task (while it’s not the limited to it). However, for 2019.1 the plan is to polish current functionality and fix issues. Then we plan to address tasks like remote debug-only mode that you describe. We plan to get it in 2019.

  14. HGH says:

    Convince BlackBerry, IBM and others to ditch eclipse in favor of your platform.

Leave a Reply

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