What to expect? CLion 2018.3 roadmap


A big CLion 2018.2 release has happened just recently. Have you tried the new version yet? If not, get your free 30-day trial on our site now. Clangd, new project models, Google Sanitizers, and many other goodies are waiting inside!

Meanwhile, we’ve already discussed and planned future improvements for CLion and would like to share our plans with you. But first, let’s follow our good tradition and thank our evaluators!

Special thanks

We’d like to thank all evaluators for helping us ship so many great new improvements in CLion 2018.2. The huge variety of your projects and setups made this task much easier for us! These 3 contributors to CLion’s Early Access Program deserve a special mention:

  • Sebastian Hofstetter – we’d like to especially thank Sebastian not only for detecting a clangd issue on Windows, but also for his detailed investigation which led to easy and quick understanding of the problem on our side.
  • Tesla Ice Zhang
  • Alexey Klimkin

In appreciation of your efforts, we present each of you with 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 any email from us within a week, ping us here in the comments.)

CLion 2018.3 roadmap

We’re keeping focus on the major directions outlined previously, but we now have a clearer vision of particular areas and tasks.

Note: The following is a preliminary plan; we cannot guarantee that all of the features listed below will be included in CLion 2018.3.
  • C++ Support:
    • Clangd-based language engine requires some polishing of the current code, fixes on Windows, and several general pain-points. We’ll also consider moving other code insight features (at least some local ones) to this language engine, one by one.
    • Bug fixing in the current language engine. Better C++17 knowledge will likely be also added to CLion’s own engine.
  • IDE performance:
    We’ll continue our incremental job of fixing UI freezes and improving performance across the board.
  • Remote development:
    The first prototype is under development and we really hope to include it in v2018.3. The target system will likely be limited to Linux.
  • Project Models:
    • Improve compilation database integration in CLion.
    • Add an ability to build/run projects from compilation database through user-defined commands.
    • Investigate other project models and continue our work on project model API in CLion.
  • Formatter:
    • Integrate clang-format as a separate tool for explicit code reformatting.
    • Consider importing formatting settings from the clang-format files.
  • Debugger:

As usual, your feature requests and suggestions are welcome in our tracker.

Your CLion Team
The Drive to Develop

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

36 Responses to What to expect? CLion 2018.3 roadmap

  1. Dmitry Nezhevenko says:

    CMake Ninja generator please… GNU make is one of major bottlenecks for a lot of people..

    • Anastasia Kazakova says:

      We are considering CMake server integration which may solve this. Ninja on its own has some issues we can’t overcome easily for now.

      • Jakub says:

        You can use CMake server or whatever else you need 😉

        But we need something faster than make because right now simple re-run (no changes) takes like 7 seconds on my current project and is simply annoying.

        (Please don’t take it as an angry comment – it’s not 😉 )

        • Roman says:

          Yeah, zero-builds are painful on Makefiles. This is the reason why I’ve restructured my codebase into a multiple projects.

        • Anastasia Kazakova says:

          We definitely realize that ninja is a better choice in terms of speed. The problem is that Ninja generator from CMake produce output that doesn’t include all the information we need in the IDE about the project (in comparison with Makefiles for example). So just adding support for another format doesn’t work.
          CMake server may solve this, but that’s a huge thing to integrate with unfortunately, as it changes the whole logic of working in CMake on our side.

          • Krzysztof says:

            What are you missing from ninja projects? Can you share?

          • Anastasia Kazakova says:

            There is some information about the project missing in the ninja generator output, at least when we looked at it there were some gaps, maybe we need to investigate it more carefully. I don’t have a list at my hand now.

          • Jakub says:

            Just a though:
            For Makefile and Ninja generators one can set CMAKE_EXPORT_COMPILE_COMMANDS to get CMake to create compilation database. If I’m not mistaken, Clion can now work with it.
            So what about just passing “-DCMAKE_EXPORT_COMPILE_COMMANDS=ON” to the CMake invocation and using the generated compile_commands.json?

          • Anastasia Kazakova says:

            This is possible, yes, but CMake with Makefiles is a much better project description as compdb, as compilation database exclude all information about the linking and you can’t build/run your project.

          • Jakub says:

            Meh, that’s a bummer.
            I really look forward for Ninja to work within CLion. Hopefully you’ll nail it in not-too-distant future.

          • Anastasia Kazakova says:

            We hope that too!

  2. Tano says:

    It’s nice that you improve the debugger, there are several problems also with it, besides the hex and the memory view.
    Some of them: CPP-13262 CPP-13640 CPP-13448 (this worked perfectly in 2017) IDEA-195289 IDEA-195290

    • Eldar Abusalimov says:

      Hi Tano,

      We kind of fixed the first three tickets (those from the CPP tracker) in master, but there were few potential performance issues discovered w.r.t. to expensive resolve operations involved in expression evaluation, so we decided to make more thorough effort on fixing before releasing them. Please, rest assured we’re keeping an eye on these.
      I can’t comment on IDEA tickets though, since changing that behavior affects other IntelliJ-based IDEs, not only CLion.

      • Tano says:

        Thank you very much for the status, Eldar.

      • mbalabin says:

        Eldar, great many thanks for your work on debugger support! I use CLion since the earliest versions and debugging is much, much smoother now (especially with LLDB).

        What is spoiling my experience the most now are CPP-10235/CPP-12472 problems. I noticed that CPP-10235 was moved to develop and then to test in June but made no further progress. Is there any chance that these tasks will be moved forward in 2018.3?

        • Eldar Abusalimov says:

          I hope so! Thanks for bringing the attention to these tickets, Mikhail.

          CPP-10235 is too broad so that we couldn’t just close it since many STL still don’t render correctly with LLDB on macOS. There was an attempt to fix (unordered_)(multi)(map|set) formatters, but our QAs discovered some issues while testing formatters for the rest containers.

          • mbalabin says:

            Indeed, there are too many possible combinations of compiler, STL and debugger versions. If something does not match then lldb can not pretty-print anything even on its command line.

            Maybe, it would be easier to tackle the problem starting from simpler case when all components do match. For example, I use a “native” clang6 + lldb6 + libc++6 toolchain from Ubuntu 18.04. Everything is printed just fine either on lldb cmdline or in explicitly added watch, but not in local variables, which seems weird.

          • Eldar Abusalimov says:

            I wish the setup you described was the only one, haha :) You’re right indeed, LLDB seems to be more picky than GDB when it comes to environmental differences, according to my feelings at least.

            Thanks for the reference example, we’ll try it too (frankly speaking, the last attempt to resurrect LLDB formatters was macOS only, but still quite chaotic regarding to the setup differences).

  3. Fabian Knapp says:

    It would be a big thing for our company development if CLion would integrate custom toolchains like the widely used Yocto project for embedded development.

    • Anastasia Kazakova says:

      What do you mean under integrating custom toolchains? Support compiler, CMake, debugger? Currently all GCC-based compilers are supported and you can submit others to our tracker for consideration.

  4. Lyosha12 says:

    Hi. CLion was and is for me as a beam of light in my first steps in development in university. Yours static analiser, code highlighting. All gorgeous and with each release getting better and better.

    All my first programms are use external windows terminal. Using CLion I wrote one of few program which forced the teacher to think that it was written not by me…
    I would hardly repeat this result now because start debug my console application is hard. For this I need to attach to console procces via menu. I spended on this a lot of time until I leaved from ‘hot’ development in console.

    This was happen when CLion ‘got rid’ of bug while when debuging application the external console was runing. I don’t know why it is a bug, but now develop ‘native’ console application on windows are hard.

    I don’t expect what CLion team will be add this feature (again) soon, but helping for my friends in university I forced to use other IDE, because it’s faster.

    So, corresponding ticked was created a long time ago
    And my post refers to it: https://intellij-support.jetbrains.com/hc/en-us/community/posts/115000728664-Clion-2017-3-Separate-console-window

    • Anastasia Kazakova says:


      We are sorry the problem affects you in this way. We’ll consider it for the next versions. There is some technical issues with it, but we’ll try to allocate and put some efforts into it.

  5. Helge Penne says:

    Is there any hope of getting post mortem debug support? This would be very useful. It is an expected feature in a modern IDE, really:

    • Anastasia Kazakova says:

      It’s definitely in the short list. However, we are lacking the resources in the debugger area and there are currently tasks with higher priority. But hope to get to this one soon.

  6. Tano says:

    Hi Anastasia, can you tell me what is the “V”-shaped icon near CMakeLists file in my image? It seems that is not a bookmark, I deleted all of them.

    • Anastasia Kazakova says:

      ‘V’ is a bookmark. Seems you’ve toggled a bookmark on this file (may by by incident). The list of bookmarks to edit is available in Favourites tool windows.

      You maybe deleted all of them in the file, but there is still a bookmark on the file itself? Check in the tool window

      • Tano says:

        Thank you, I deleted all the bookmarks and the icon was still there. After CLion restart, it seems to go away. Thanks a lot :)

        • Anastasia Kazakova says:

          Interesting, if you see this happens again, maybe try to report it to IDEA tracker with some logs and settings/caches packed. To me it goes away immediately.

  7. Hi.
    Remote development is the only feature is still bothering us, stoppng our processes of migrating from Netbeans.

    Remote development:
    The first prototype is under development and we really hope to include it in v2018.3. The target system will likely be limited to Linux.

    Looking forward to this feature.

    Any chance to test it in upcoming EAP?

  8. On the original plan for 2018.x there was a mention for CTest support. Is it coming in a near future ?. We desperately need it we have 100 of test which are wrapped in CTest to able to run on different target platforms remotely and in qemu. It is really painfull to configure of these settings over the confgure menu of the gui.

    • Anastasia Kazakova says:

      Unfortunately, we had to postpone CTest for a while, as we update/improve our general unit testing API / integration in CLion. This should solve many performance issues, so it has higher priority for now.

  9. HGH says:

    What is your stance on performance? I guess Android Studio has a lot if not 100% in common with CLion. AS + gradle + cmake is slow. Really, really slow and memory hungry.

    • Anastasia Kazakova says:

      AS is not build on top of the latest CLion version, it has some delays with delivering the improvements. CLion 2018.2 got a huge set of performance fixes, hopefully Google will incorporate them soon into AS.

  10. Roman says:

    When do you plan to support free functions auto-completion in Clion https://www.reddit.com/r/cpp/comments/6ik3p4/now_that_modern_ides_support_dotcomplete_to_free/ ?

Leave a Reply

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