Moving into 2019. CLion roadmap

Posted on by Anastasia Kazakova

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

Comments below can no longer be edited.

73 Responses to Moving into 2019. CLion roadmap

  1. Tano says:

    December 3, 2018

    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:

      December 3, 2018

      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:

        December 3, 2018

        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:

        December 4, 2018

        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:

    December 3, 2018

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

      December 3, 2018

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

  3. Mike says:

    December 3, 2018

    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!

    • Anastasia Kazakova says:

      December 3, 2018

      I suppose this workaround is even hacked in some kind of a plugin: http://nevkontakte.com/2015/rogue-ninja-support-in-clion.html
      But we of course plan to support ninja natively, it just has some tech issues and postponed till some other important tasks are handled. It might be handled by introducing CMake Server support

    • Dmitry Nezhevenko says:

      December 4, 2018

      Have you tried Jom? https://wiki.qt.io/Jom
      It’s just parallel nmake implementation. I’m not sure that it’ll work with CMake-generated Makefile. But it should be easy to try.

      PS. I fully agree that Ninja support is a must have thing now

  4. Fabian says:

    December 3, 2018

    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

    • Anastasia Kazakova says:

      December 3, 2018

      Yes, we plan to have it, probably somewhere next year.

  5. Henry Borchers says:

    December 4, 2018

    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:

    December 4, 2018

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

    • Anastasia Kazakova says:

      December 4, 2018

      No such plans for the Rust team, but they might consider it in the future.

  7. johnthagen says:

    December 4, 2018

    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.

    • Anastasia Kazakova says:

      December 4, 2018

      We’ll check if that fits. Can’t promise you, but we’ll take a look.

  8. johnthagen says:

    December 4, 2018

    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

    • Anastasia Kazakova says:

      December 4, 2018

      We’ll check. Maybe we can indeed do so

  9. Roman says:

    December 4, 2018

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

    • Anastasia Kazakova says:

      December 4, 2018

      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:

    December 5, 2018

    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:

      December 5, 2018

      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:

        December 5, 2018

        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:

          December 5, 2018

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

          • Helge Penne says:

            December 13, 2018

            I’ve turned it back on, and it seems to be working now. i did an “invalidate cache” and it is possible that this helped. I will file a bug report if it shows up again.

            • Anastasia Kazakova says:

              December 14, 2018

              Thank you! Glad it works now

  11. TheLordofdirTB says:

    December 5, 2018

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

    • Anastasia Kazakova says:

      December 5, 2018

      We hope to get better C++17 soon, especially big hopes go to clangd-based complementary engine.

  12. Alexey says:

    December 6, 2018

    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:

      December 6, 2018

      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:

    December 6, 2018

    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:

      December 6, 2018

      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:

    December 8, 2018

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

  15. Lamonte says:

    December 12, 2018

    SCons support is still going strong, why not cave and give it to us? https://youtrack.jetbrains.com/issue/CPP-1102

    • Anastasia Kazakova says:

      December 13, 2018

      It’s indeed quite popular, but there are other project models more widespread among C++ developers, still not supported in CLion.

  16. Jerome says:

    December 12, 2018

    One question torments me) why are you implementing work with embedded? Votes for working with embedded systems are much smaller than with many others. I give for example Qt, Makefile.
    Why not to realize what people most want?

    • Anastasia Kazakova says:

      December 13, 2018

      We rely on many factors, not only YT votes. Embedded development is a top priority direction for us and always was, but the resources were much more limited than now. Initially, when started CLion, we analyzed the C++ market and found out that 3 directions are trending for C++: financial/trading, embedded and gamedev. So embedded dev is selected not only because of the votes, but also because of the many other factors.

      Regarding the project models, we expect Makefiles to be the next project model to support, however currently there are many activities in the core project model functionality which goal is to build an API for project models. We need to finalize it to some extent first, then we can move further with adding other project models.

      qmake is a very questionable project model in current circumstances. Qt recently deprecated qbs and seems will be moving towards CMake now. Doesn’t seems like a good argument to support qmake in that sense.

      • Jerome says:

        December 13, 2018

        I understand you, thanks for the reply. But as for Qt, I had in mind the creation of a Qt project with a project relish file cmake. Macro support is very necessary.

        • Anastasia Kazakova says:

          December 14, 2018

          What are the problems with Qt macro now in CLion? In general, you should be able to open a Qt CMake-based project in CLion and develop it w/o any problem.

          • Jerome says:

            December 17, 2018

            http://doc.qt.io/qt-5/properties.html
            CLion does not have Qt macro code generation support at all.
            CLion can not generate code from macro Q_PROPERTY
            Q_ENUM
            Meta type
            Q_SIGNAL
            Q_SLOT
            Q_OVERLOAD
            Q_FLAGS
            Q_OVERRIDE
            I can continue the endless list))

            • Anastasia Kazakova says:

              December 17, 2018

              What do you mean under “macro code generation support”? Can you please explain.
              When imported, it’s parsed correctly in my case. Maybe you can share a code sample and a problem description? Thank you

          • Jerome says:

            December 17, 2018

            For example, you can enter the macro Q_PROPERTY and display the possibility of using parameters. When you mean this kind
            Q_PROPERTY(Priority priority READ priority WRITE setPriority NOTIFY priorityChanged)
            further, for example, from the context menu you choose to generate code, you will get this result

            public:
            void setPriority(Priority priority)
            {
            m_priority = priority;
            emit priorityChanged(priority);
            }
            Priority priority() const
            { return m_priority; }

            signals:
            void priorityChanged(Priority);

            private:
            Priority m_priority;

            • Anastasia Kazakova says:

              December 18, 2018

              Ah, so you mean a very specific Qt macro functionality. This might be interesting, feel free to put into the tracker as a feature request: https://youtrack.jetbrains.com/issues/CPP
              And maybe more cases you have here in mind.

  17. Roman says:

    December 13, 2018

    Auto-completion performance and refactoring quality are two most annoying problems. Wish to see improvements next year.

    • Roman says:

      December 13, 2018

      And ninja builds and MSVC debugger of course 🙂

    • Anastasia Kazakova says:

      December 13, 2018

      We hope to provide them. Autocompletion is first in the list.

  18. Anonymous says:

    December 18, 2018

    Roadmap is nice, I hope CLion 2019.1 support other build system, like make, autotools.

  19. Michael Reid says:

    January 5, 2019

    As you focus on adding embedded support this year. Love the support for microcontroller development.

    However, is there a effort to look into Yocto builds? This would be useful for us that build full linux bsps for ARM platforms. I understand that Yocto is a group of build tools (bitbake as anexample).

    • Anastasia Kazakova says:

      January 7, 2019

      Thank you for a suggestion. We gonna start with STM family, then move on to the others. Embedded is huge indeed, so we’ll definitely go step by step there. Feel free to add suggestions to our tracker: https://youtrack.jetbrains.com/issues/CPP

  20. Anton says:

    January 5, 2019

    Hello,
    The question is, are you going to implement support for interface libraries?
    I mean projects that have targets like this: add_library(${PROJECT_NAME} INTERFACE).

    For now working on header only projects is similar to working in notepad.

    • Wojtek says:

      January 7, 2019

      I also faced this problem before.
      But there is a solution. You have to create a standard project (an executable lets say) and then link your header only library to this executable. This way you will have all the fancy IDE stuff (autocompletion, syntax validation, etc.)

      • Anastasia Kazakova says:

        January 7, 2019

        Yes, this is the third workaround) Thanks

    • Anastasia Kazakova says:

      January 7, 2019

      This will be resolved by supporting CMake server (https://youtrack.jetbrains.com/issue/CPP-8238, https://youtrack.jetbrains.com/issue/CPP-8472). The problem is that when header only projects are in CMake and the headers are not listed explicitly in CMakeLists.txt files, CMake doesn’t count these header files as project files, neither does CLion in that case. That’s why the problem is. Two workarounds for now: when the header is used in some .cpp (or other project file), CLion counts it as a project one automatically, even when not listed explicitly in CMake. Or you can mard directory as sources (in the context menu on the folder).

  21. Gregory Kramida says:

    January 8, 2019

    Hello,

    are there any plans to address performance issues related to usage of the popular Eigen library and similar libraries in 2019?

    A lot of us are upset about it, see https://intellij-support.jetbrains.com/hc/en-us/community/posts/360000535360-CLion-is-very-very-slow

    -Thanks

    • Anastasia Kazakova says:

      January 8, 2019

      We are addressing them step by step in each release/update. Do you mean anything in particular? Can you please point to the issue in the tracker or provide a CPU snapshot? I can then update you on the status.

      • Gregory Kramida says:

        January 9, 2019

        I had already done that before for 2018.2, here: https://intellij-support.jetbrains.com/hc/en-us/requests/1825064?flash_digest=92b10f0e8ff50d3760df824878cb58642fa589a3

        There were no positive changes to any of the reported issues in 2018.3.

        I’ve just opened a performance problem report for a very specific issue — excruciatingly slow “Go to Declaration” for functions whenever Eigen is involved, with “Resoliving Reference…” hanging on the screen for upwards of 10 seconds for even the most basic projects: https://youtrack.jetbrains.com/issue/CPP-15082. If we can tackle this, we can start tackling other performance issues — slow-downs in refactoring, debugging, etc.

        • Anastasia Kazakova says:

          January 10, 2019

          Thanks, we’ll take a look and respond in the ticket.

  22. PM says:

    January 11, 2019

    Help pls.

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

    Bought CLion at summer 2018, but did’t receive email…

    • Anastasia Kazakova says:

      January 11, 2019

      Do you mean a free license? Were you listed above?

  23. Miao says:

    January 11, 2019

    Do you have any plan to implement core dump file analysis with GDB?

  24. Ryan says:

    January 14, 2019

    This generally looks good. The performance issues/freezing are definitely the main thing stopping me from recommending CLion to other people right now.

    • Anastasia Kazakova says:

      January 15, 2019

      Any particular issues from the tracker? We can check when we are gonna address them.

      • Renat says:

        February 22, 2019

        For example look here https://youtrack.jetbrains.com/issue/CPP-8459
        Once I’ve got 4-minute full freeze on X1 Extreme (i7-8750H with 6(12) cores). You shouldn’t make heavy analysis in EDT. And probably there is a room for multi-threaded optimization too because I’ve seen in htop that not all cores were busy.

        • Anastasia Kazakova says:

          February 22, 2019

          That’s indeed a very bad issue that we definitely need to fix. We are on it and hope to fix it, investigating a proper fix.

          • Renat says:

            February 23, 2019

            Thank you! Glad to hear it!

  25. llvim says:

    May 16, 2019

    Clangd-based engine is very very slow, it freeze my mac book pro 2015 everyday

    • Anastasia Kazakova says:

      May 17, 2019

      Why are you sure it’s a clangd engine? If UI is freexing, the thread dumps are generated automatically in the logs directory (Help | Show Log). Is there anything?

      • llvim says:

        May 17, 2019

        when i disable enable clangd server, clion do not freeze

        thread dumpps log is something like this ? threadDumps-freeze-20190515-152834-CL-191.7141.37-497sec

  26. Rob Wehrli says:

    September 18, 2019

    Anything to update in terms of the embedded support road map progress?

Subscribe

Subscribe for updates