CLion 2016.3 roadmap

Hi everyone,

Last week we released CLion 2016.2, which we feel is a great update that brings many long-awaited features, like Doxygen support, operator generation and remote GDB debug.

Now it’s time to move forward. But before we share the upcoming plans with you, let us first say thanks to all our evaluators!

Special thanks

We thank all of you who evaluated CLion during the Early Access Program, provided your feedback and suggestions, and submitted issues to our tracker. You’ve made it possible to release a new feature-rich and stable version, which we hope helps you become a true C++ guru.

We’d like also to mention several contributors who deserve special kudos and a free 1-year subscription (to extend your current subscription or get a new one):

  • Neronyatkin Vitaly (YouTrack handle: neronyatkin)
  • Alexey Dmitriev (YouTrack handle: RiaD)
  • Michail Tolstoy (YouTrack handle: tolstoymv)
  • Anon Anonchik (YouTrack handle: aanonchik)

A personal message will be sent to each of you guys with details on how to obtain your license. (And just in case you do not get any email from us within a week, ping us here in the comments.)

Further plans

Here are some things we had planned for CLion 2016.2 but which will only make it into the upcoming 2016.2.x updates. These are:

  • Ability to watch command output during CMake execution.
  • Several parsing problems which lead to red code in JUCE libraries (OC-8211).

We’ve also discussed all the feedback we got from you, looked at our tracker and spent some time analyzing all these sources. This helped us come up with a preliminary plan for 2016.3.

Please note it’s a preliminary plan, so we can’t guarantee that all of the features listed below will be included in CLion 2016.3.
  • Performance:
    We feel this is a good time to put a major effort into performance improvements. If you experience any issues at all with CPU and memory usage or face any UI freezes, please let us know! Check this page for the list of dumps and snapshots that can be useful for us to investigate and localize the problem.
  • Language support:
    • Fixes to overload resolution (linked to this ticket mostly).
    • Problems with friend and using aliases.
    • Support for user-defined literals (C++11).
    • Support for C++14 digit separator.
    • If we still have resources left, we may devote some time to _Generic command (C11).
    • There is also a list of regressions that we need to go through.
  • CMake:
    • Support for add_custom_target command (if you face any problems with this command in CLion, please describe them here).
    • Ability to specify the build/generation output directory.
    • Ability to specify build types (Debug, Release, etc.).
    • Reload performance improvements.
    • Ability to select Ninja generator instead of Makefiles.
  • Debugger:
    • Remote GDB debug on Windows.
    • Disassemble view.

As before, if some features from the above are not ready for 2016.3 release (that hopefully will be available before the end of the year), they still can be delivered in 2016.3.x updates.

Stay tuned and don’t to miss the EAP launch.

Give CLion a try for free with a 30-day evaluation!

Your CLion Team

JetBrains
The Drive to Develop

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

19 Responses to CLion 2016.3 roadmap

  1. Gauthier P. says:

    Nice roadmap ! :)
    Disassemble view is a very useful thing, in particular when we want to understand how things work (useful for studies).

    I also hope it’ll come with a basic support of Assembly language (syntax highlighting and maybe basic completion). I tried different way to write Assembly (text editor, “Assembly” IDE, …) but never found something really pleasant to use !

    Fix for regressions (in particular incorrect includes of , an issue exist for that) are nice too. :)
    Looking forward to try this EAP ! :)

  2. Olof says:

    This is awesome. I’ve thought more about what it is that I think is the most important improvements for CLion for the way I work and it boils down to:

    1) parser correctness and refactoring/code generation and
    2) red/green/refactor feedback loop speed.

    So for me this roadmap is like a dream come true. I’ll be waiting excitedly for each EAP. And on that topic, I find the quality of your EAP’s to be very high so kudos for that.

    PS.
    The biggest red code issue for my code base is gtest and gmock code. Admittedly those macros are pretty gnarly. I don’t know if there is one issue causing all that red code or if there are 200 issues, but if it is a simple fix it’ll remove 80% of the red code in my use case. Or maybe there is something wrong with my gtest install if I’m the only one with this issue?

  3. Henry says:

    Remote GDB debug on Windows??? Oooo! That’s be awesome.

  4. Rishabh says:

    Does the conditional breakpoint feature work or is it broken, because it never breaks if I set a conditional breakpoint (even when the condition is “true”). I am using latest EAP build

  5. Jakub says:

    Any plans on attacking https://youtrack.jetbrains.com/issue/CPP-3109 ?
    It bites me constantly.

  6. John says:

    Would love to see a Community Edition be explored. I find it a lot easier to recommend and introduce new developers to IntelliJ and PyCharm because there are Community editions they know they can use long term. I don’t know the market research on this, but in my experience, this has lead many of these developers to purchase licenses at their workplace who would have not otherwise been exposed to JetBrains products.

    In any case, looks like a great road map — especially remote GDB on Windows!

    • Anastasia Kazakova says:

      Thanks!

      We do not plan Community Edition at this stage. But there are free licenses for education and open source developers.

  7. Liam Coughlin says:

    more c++… no c…

    sadness.

  8. Marek Lukáš says:

    Is the C project creation wizard being worked on?

  9. Charles W. says:

    Is there an update on using CLion to build projects using VC’s cl.exe instead of a gnuish compiler chain? The latest updates from Code hinted that they’ve made it possible even to debug from outside the VS IDE.

    If I could use the MS toolchain on Windows and gnuish on Mac and Linux, it would be the trifecta, even if it requires the installtion of vs-clang.

    • Anastasia Kazakova says:

      Currently it’s not possible. Find the related feature requests:
      https://youtrack.jetbrains.com/issue/CPP-819
      https://youtrack.jetbrains.com/issue/CPP-6352

      • Charles W. says:

        Can you go into why it’s not possible? You could still use bundled clang for code intelligence while allowing CMake builds to target an installed Microsoft toolchain. It’s simple enough to switch to the terminal to do builds and run– I can’t imagine that doing it from within the UI is out of the realm of possibility.

        I’m even good if debugging is not possible. I just want builds so I can get away from the VS IDE. :)

        • Anastasia Kazakova says:

          We need some information from the compiler, like compiler predefined macros for example. This info is taken directly from the compiler, so CLion works with GCC, clang and Intel. However, Microsoft toolchain is different. Besides, there could be issues with some resolve and other things when Microsoft toolchain is used. So we need some resources to work on it and find a solution.

Leave a Reply

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