Where are we going? CLion 2018.2 roadmap


Just recently we’ve released CLion 2018.1! It improved C++ support with dozens of fixes and several important C++17 features supported, provided the ability to compile, run, debug and run with Valgrind Memcheck Linux binaries on Windows using the WSL toolchain, added CMake Install and started the general decoupling of the CMake project model from CLion, enlarged the supported family of languages with Rust and Fortran, and much more.

Now it’s time to thank our evaluators for their great help and share plans for 2018.2 coming in mid 2018.

Special thanks

It always happened to be quite hard to check new changes in all possible environments and configurations, so evaluator’s help is always highly appreciated, as they help us to make the release stable and feature-rich. We have an ongoing tradition to thank our most active EAP evaluators here in the blog and present each of them with a free 1-year subscription for CLion (to extend their current subscription or get a new one). This time we’d like to issue a special thank to the following contributors:

  • Taw Moto (YouTrack handle: tau.xxx)
  • Oliver Stöneberg (YouTrack handle: Firewave)
  • Sascha Kratky (YouTrack handle: sakra)

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 2018.2 plans

We’ve already outlined the major directions and priorities for this year: improve C++ support (both in terms of correctness and IDE performance), focus on remote development and enrich the project models support. These goals remain, and the plans for 2018.2 are all created with these directions in mind.

Note: The following is a preliminary plan; we cannot guarantee that all of the features listed below will be included in CLion 2018.2.
  • C++ Support

    While considering different alternatives to the current language engine, doing various tests and measurements, we still work hard on the current implementation, fixing bugs and adding support for the new language features:

    • More C++17 features
    • Fixing issues with incorrect code parsing, resolve and false code analysis warnings across different code bases and code samples
  • IDE performance

    We’ve collected and sorted dozens of various freeze dumps and snapshots, and started working on globally improving the situation in 2018.1. Better typing performance was just the first step. We’ll continue to fix cases with freezes on typing, completion and some other popular IDE actions.

  • Compiling / Running / Testing
    • Add an option to (re)compile single files
    • Add Google Sanitizers support
  • Project Model
    • Continue with decoupling CMake from CLion, work on project model API
    • Investigate alternative project models
  • Debugger
    • Improve experimental hex support in debugger
    • Add memory views
    • Add LLDB disassembler support
  • Remote development
    • Implement first prototype for remote development support, limit target system to Linux, other limitations are possible
    • WSL support improvements

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.

43 Responses to Where are we going? CLion 2018.2 roadmap

  1. Arthur says:

    Hello, speaking of performance, I’m curious of the language repartition of the Clion code (e.g. percentage of Java / C++ code).
    Having more IDE code in C++ certainly improves performance, though more difficult to develop.

    • Anastasia Kazakova says:

      The code is in Java and Kotlin. But the language of the implementation doesn’t affect it in that sense. Performance issues are mostly related to the complicated C++ parsing and resolve and platform architecture.

      • HGH says:

        What are these C++ alternatives?
        Your realized that it is best to use a real compiler’s front-end (Clang) than trying to do your own parser?

        • Anastasia Kazakova says:

          That’s not fully correct. Compilers have different goals – they need to resolve symbols immediately in order to process the whole code, they do not deal with incorrect code (simply stop) and so on. IDE’s engines behave in an opposite way. Clang as a compiler is quite slow w/o additional optimizations if used as a language engine for the IDE, and also doesn’t provide proper cache to perform refactorings on the whole project, not TU.

  2. Tano says:

    Thank you for the license, I really love CLion and the team that always helped me with my issues.
    It seems that I timed my new bug perfectly because so I can use the old settings with a new account. :p (CPP-12549)

  3. Sébastien Duquette says:

    Happy to see support for Google Sanitizers on the roadmap!

  4. Andrew Smith says:

    In the 2018.1 roadmap, remote debugging over SSH (without gdbserver) was listed as a possiblity. Might that make it into 2018.2?

    • Anastasia Kazakova says:

      We hope for that. We’ll start working on it during this cycle and if we have smth in production quality, we’ll release the feature.

  5. Henry says:

    CTest support isn’t in this roadmap.

    Oh well. Looks like you have a lot of other interesting things coming up.

    Keep up the great work.

    • Anastasia Kazakova says:

      If we have some time, we’ll try CTest, but the corresponding resources are busy with other tasks for now.

      • Henry says:

        Thanks Anastasia. I completely understand that you have bigger goals. I can’t imagine how much work you are going to have to do under the hood to decouple CMake from CLion.

        Using CTest from the command line for now is okay with me. As a CLion user from the first public beta, I’m just happy with how awesome CLion is already. Everything additional feature added makes my life a little bit better.

  6. Jan says:

    Please take a look at fixing https://youtrack.jetbrains.com/issue/CPP-10235 for the next release. This issue makes debugging really painful.

  7. Raphael says:

    > Continue with decoupling CMake from CLion, work on project model API

    Cool, there’s hope for a Swift IDE on non-Mac! \o/

  8. Jakub says:

    Great to see sanitizers on the road map. The more tools I have available from inside of the IDE, the better.
    Sanitizers, CTest, profilers, other tools from Valgrind package (cachegrind, helgrind, massif) are high on my wishlist. Other things include some kind of superbuild / multiproject support with interproject dependencies (there are several tickets for that).

  9. Alex says:

    Very much looking forward to the remote project/debug support!

    Also is there any chance of using ninja generator for CMake (https://youtrack.jetbrains.com/issue/CPP-2659 or https://youtrack.jetbrains.com/issue/CPP-870)? I mostly use CLion to work on LLVM+clang and for single file changes using ninja instead of make gives a massive speedup (<5 seconds instead of almost 1 minute). Maybe using cmake -G "CodeBlocks - Ninja" instead of cmake -G "CodeBlocks - Unix Makefiles" gives all the required information?

    • Anastasia Kazakova says:

      It doesn’t and that’s the problem. Unfortunately, seems the easiest way to deal with ninja will be to move to CMake server. This is currently under investigation, but no exact plans or estimations.

      • Dmytro says:

        If I remember correctly QtCreator used CodeBlocks+Ninja and CodeBlocks+Makefiles cmake generators, hopefully addings CodeBlocks may help to provide the missing information.

  10. Olof says:

    Can you elaborate on this?

    > While considering different alternatives to the current language engine

    • Anastasia Kazakova says:

      Not at this stage, unfortunately. We are investigating various ways to improve current language engine, we have some tests, previews and experiments under the hood, still we are not ready to speak about it in details now.

  11. Sidney Just says:

    Does this mean that support for MSVC debugging is not coming anytime soon? Unfortunately I can’t use CLion at all for work due to this, being able to compile using the MSVC toolchain is great, but debugging applications is sadly vital to development.

    Not trying to complain, I think you are doing a fantastic job, but right now I’m stuck with Visual Studio and Resharper (which makes things a lot better, but still)

    • Anastasia Kazakova says:

      Unfortunately, that’s not clear for now if we are able to get the debugging for MSVC soon. But it’s under investigation.

      • Henry says:

        I love that I can now use my favorite C++ IDE for writing Python C extensions on Windows for MSVC (3rd party packages for Python compiled with MinGW is a nightmare) at work.

        Out of curiosity. You’ve had MSVC support without a debugger for some time now. What is the thing that is holding you back from implementing the debugger for MSVC? Resources dedicated elsewhere, licensing from Microsoft, lack of interest from your users, or is it really difficult?

        • Anastasia Kazakova says:

          Resources are very limited here, as there are plenty of other tasks around debugger. For MSVC we have to implement a full-featured debugger from scratch, not just an integration interface as it’s done for GDB and LLDB. There is simply no proper debugger you are use for free for MSVC case.

  12. Nestal Wan says:

    It’s great news that remote development is included.

    Does it required WSL for a Windows client to develop in Linux machine remotely?

    Another question, if I am using a Linux desktop and my build server is inside a docker container. Can I use the new remote development feature?


    • Anastasia Kazakova says:

      Remote development feature doesn’t require any WSL. When it is available, you can develop remotely on Linux from your Windows machine.

      Docker containers can be configured as a regular remote host, so shouldn’t be a problem.

      • Nestal Wan says:

        Thanks Anastasia.

        I renewed my subscription because of remote development. That is a very important use case for a lot of people.

        Thanks again.

  13. John says:

    Would really like to see support for emplace_back style functions in CLion, we lose a lot of valuable code insight from CLion when using these functions: https://youtrack.jetbrains.com/issue/CPP-8043

    Would love to see a little love put towards Doxygen as well:

    – Color parameter names: https://youtrack.jetbrains.com/issue/CPP-10311
    – Highlight incorrect parameters: https://youtrack.jetbrains.com/issue/CPP-9282

  14. Kamil Becmer says:

    Is there any chance to support clang’s native Windows compiler as alternative to MinGW and MSVC?

Leave a Reply

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