What’s next? CLion 2018.1 roadmap


Two weeks ago we released this year’s third big update – CLion 2017.3! It made C++ code analysis more accurate in many areas and added support for MSVC extensions, integrations with Valgrind Memcheck and Boost.Test, and many other improvements and new features.

Now we’re ready to share with you our primary directions for 2018 in general and the roadmap for v2018.1 in particular.

Special thanks

Before moving on to our plans for 2018, let’s follow our good tradition and thank those who helped make CLion 2017.3 feature-rich and stable! These four contributors to CLion’s Early Access Program deserve a special mention:

  • Roman Popov (YouTrack handle: ripopov)
  • Chris Uzdavinis (YouTrack handle: cuzdav2)
  • Roger Dubbs (YouTrack handle: rogerdubbs)
  • Tomasz Grabiec (YouTrack handle: tgrabiec)

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 in 2018

First, I’d like to outline our major directions and priorities for 2018, and then share the roadmap for 2018.1 that is in line with the general plan.

C++ language support and IDE performance

We talked in the past about our plans for big overhauls in several problematic areas of the C++ language engine. We’ve got overload resolution, list initialization, and name lookup there already. The latter still needs some extra work, and then we’ll move forward.

We would also like to focus more on performance, especially on your user experience while typing. We’ll dedicate the next release cycle to fixing IDE freezes.

You can pitch in, too! We’ve posted a call for test projects on Twitter and would appreciate links to any open source projects you are working on in CLion.

Remote work, WSL

After a general investigation of the topic, we’ve come up with a plan to introduce remote development support in CLion. This will all start with support for Windows Subsystem for Linux, so that our Windows users can benefit from Linux toolchains. The general mechanism will also serve as a preparation for further remote development support in CLion.

CMake & other project models

CMake is growing impressively, and we are thrilled to see this trend continue over the past years (per Google Trends, 11/11/2014 thru 11/12/2017):

However, there are other worthy project models in the C & C++ development world that seem to be quite popular, and custom project models are used in many projects as well. This is why we are finally starting to decouple CMake from CLion. This will allow for supporting new popular project models, as well as an API for those who’d like to implement plugins for custom project models for CLion.

Plans for CLion 2018.1

Note: The following is a preliminary plan; we cannot guarantee that all of the features listed below will be included in CLion 2018.1.
  • C++ support
    • Continue with the overhaul in the major areas
    • Extend support for C++17
    • Fix bugs and regressions
  • Performance
    • Reduce IDE freezes
  • Project model
    • Decouple CMake from CLion; start preparing a project model API
  • Editor
    • Code fold of control flow statements (if/else, do/while, for, switch)
  • Remote development
    • WSL support
    • Remote debug via SSH (w/o gdbserver)
  • Debugger
    • Hex view
    • Memory view
  • Tools
    • Support for Google Sanitizers
    • Clang-Tidy
      • Tuning default profile (set of enabled checks)
      • Support for options and configuration files
    • Support for CTest (likely will be ready for 2018.2)

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

Your CLion Team

The Drive to Develop

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

34 Responses to What’s next? CLion 2018.1 roadmap

  1. Tano says:

    This is a great great looking roadmap!

    A question though: do you plan of optimizing the Find window? For example in IDEA-183173, also Vassiliy admitted that it’s not optimal for some cases, so he suggested an ugly workaround. IDEA-170662 is other bothersome.

    Also do you keep the old search dialog (-Dide.find.as.popup=false), at least until the new one works properly in all scenarios? I really like the old one.


    • Anastasia Kazakova says:

      Since that’s a platform feature, it’s not covered in the roadmap (as this one is mostly for the CLion team). IntelliJ platform team, as far as I know, has some plans for improving the Find in Path dialog.

      • Tano says:

        Ok, nice.
        I forgot to ask for the “make install” support (CPP-9530, CPP-838).
        Are there any plans for this in 2018.2 or 2018.3 maybe?
        I agree that your list is more important than this, but I think that “make install” has to be supported eventually, it’s an important Unix feature and the request is from 2014 after all.

        In my opinion the workaround it’s good as it is, but the text is in the wrong order (CPP-9530)

        Thanks Anastasia.:)

  2. Alex says:

    The question concerns project model, I understand correctly that the next release will support some kind of new model or not?
    How to understand correctly – Decouple CMake from CLion?

    • Anastasia Kazakova says:

      That means that the work to make CLion independent of the CMake specific will start. When it’s finished the API for other project models plug-in is possible, and likely we’ll start adding some. But I suppose we’ll spend at least one release cycle on this refactoring and unlikely the API will be fully ready and publicly available with 2018.1. But that means that you can expect other project models in some 2018.x

  3. Roman says:

    I have very high hopes on CTest support. Currently I have to manually copy-paste CTest commands with options into Clion “Run/Debug configurations” GUI. I hate to do it!

    For debugger improvements I hope you can do more in 2018. Current plan does not looks very ambitious to me.

  4. zzq says:

    if 2018.1 support wsl,whether swift plugin can be used in windows?

  5. Firat Agdas says:

    Still nomake nor Qt support? Come on guys. We are waiting for this forever.

  6. Vitaly says:

    1. When you implement new feature to the IDE, after that you will only fixed the major bugs which found later, but, unfortunately, you do not notice any customer suggestions for future improving, development and improve serviceability recently implemented feature in future. It’s frustrating. I hope that user suggestions for new features will also be quickly implemented.
    2. Do you think about implementing the diagnostic capabilities in IDE: performance profilers, memory and CPU usages? For example, such that implemented in Visual Studio Diagnostic tool.

    • Anastasia Kazakova says:


      1. That’s not fully true, to be honest. We quite often re-work the feature after first implementation and presentation in the EAP program. Could you maybe list some particular issues you are interested in? We’ll then consider if they fit our plans.

      2. We are definitely interested in such tools! This release we’ve added memory profiling with Valgrind Memcheck. Next release we plan in integrate Google Sanitizers. Then we’ll consider more tools in that area.

    • Jon says:

      And code coverage like in IntelliJ!

  7. Jakub says:

    Looks promising. Can’t wait for the EAPs :)

  8. John says:

    How about ninja support?

  9. oreak says:

    I hope the debugger show assembly language

  10. mbalabin says:

    Anastasia, are there any news on the infamous IDEA-124160? I understand that the problem is not CLion-specific and (as it seems) it has no easy solution. But I would be happy to hear someone confirm that the management is aware of the problem and understands how annoying this bug is.

    • Anastasia Kazakova says:

      We are aware of the issue and we are looking for the ways to fix it. No good solutions for now, unfortunately. But it’s constantly on our radar.

  11. it would be grate to extend the VCS support for google-repo-tool -> now it is cross platfrom
    and managing bigger project with several 10 of repos this is a must.

  12. niros says:

    Very excited about WSL and IntelliJ. Great job!

  13. Nehal Patel says:

    Hi —
    Some open source projects that I have found problematic for clion (requiring switching to emacs) are llvm (llvm+clang+libcxx+lld) (https://git.llvm.org/git/llvm, etc) (initial indexing takes minutes, small edits cause large editor pauses), the linux kernel using techniques described here (https://github.com/habemus-papadum/kernel-grok) (Initial indexing took about 10 minutes and a restart, after that experience was tolerable), Cmake (https://gitlab.kitware.com/cmake/cmake) (seems to be getting better as clion has progressed from 2106->2017), https://github.com/dealii/dealii (this project uses cmake in a non-standard way, and in some way it is to blame), and Z3 (https://github.com/Z3Prover/z3)

    In general, while it would be nice to have things simply “just work”, it might be more pragmatic to instead create tools that explain to the user exactly what clion is doing (I wonder this all the time when I see clion spinning up all my cores), and allow the user to intelligently turn off functionality when working on large or problematic projects.

    For the above projects, while clion could use improvement, in general, it is useful for certain tasks. By far the situation clion has the most difficulty is in any project that uses significant modern c++14/17 syntax (e.g. constexpr if, structured binding), auto/declexpr, complicated templated functions e.g. template <typename T, typename = std:enable_if >. There is something about how the underlying parser is implemented that when it encounters syntax it does not understand, the editor starts freezing to the point of being totally unusable — this doesn’t require a large project, 1000 lines of modern c++ can cause issues. I understand that fully supporting all these new features will take time, but I do encourage you to look for a design that gracefully degrades when it encounters syntax that it does not fully understand.

    Projects in this category are: https://github.com/aantron/better-enums, https://github.com/jscheiny/Streams, https://github.com/lewissbaker/cppcoro, https://github.com/boostorg/hana, https://github.com/ericniebler/range-v3

    Keep up the hard work!

    • Anastasia Kazakova says:

      Thanks for a great list! We tried some from list already, but some are new to us.
      C++17 mostly not yet supported in CLion, though v2017.3 makes the user experience in this case better by removing many false warnings and errors. However, we plan to add more support to C++17 in the next version!

  14. Cris Luengo says:

    I don’t have a Twitter account, so cannot respond to your call for test projects there.


    This project compiles with GCC and Clang in C++14 mode without warnings (they’re all turned on (e.g. GCC with -Wall -Wextra -Wconversion -Wsign-conversion). Only MSVC 2017 generated a few warnings related to exporting classes from a DLL (I don’t use Windows regularly…). However, Clion produces quite a few warnings in some files. Some of these issues I’ve reported in the bug tracker, but I don’t have the patience to report them all.

    Especially interesting for you might be the code that generates Python bindings using Pybind11. That uses advanced C++14 features to generate code, and much of it has red wriggly lines under it. :)

    Despite the errors in parsing, CLion is awesome and saves me tons of time. Excellent work, guys!

Leave a Reply

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