CLion 2016.2 roadmap

Hi everyone,

A week passed since we released CLion 2016.1 with so many great features and useful bugfixes. Thanks for your warm reception of this update and your great feedback!

Special thanks

Before we move forward, we’d like to thank all of you who evaluated CLion during the Early Access Program, provided feedback and suggestions, and submitted issues to our tracker. Your input was invaluable in making this release stable and feature-rich. Contribution of several evaluators deserves a special gift. We’re giving each of the following people a free 1-year subscription (to extend your current subscription or get a new one):

  • Roman Popov (YouTrack handle: ripopov)
  • Christian Hujer (YouTrack handle: cherriedquat)
  • Dave Yost (YouTrack handle: daveyost)
  • Jan Ekholm (YouTrack handle: chakie)
  • 蓝星灿 (YouTrack handle: lanxingcan)

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

New Roadmap

We spent some time analyzing the current state of the product, the issues in our tracker, and your feedback and suggestions for the new release. This helped us formulate the following plan:

Please note it’s a preliminary plan, so we can’t guarantee that all of the features listed below will be included into CLion 2016.2.
  • Debugger
    • Issues with GDB (timeouts, performance, other issues)
    • Remote debug
  • Project model (CMake)
    • Ability to watch command output during CMake execution
    • Ability to specify the build/generation output directory
    • Support for add_custom_target command
  • Performance
    • C++ code insight performance improvements
    • Formatter performance improvements
  • Doxygen
    We’ll see what we are able to finish before 2016.2 release, while in general we plan to support:
    • Doxygen comments highlighting
    • Integration with quick documentation pop-up (documentation preview)
    • Auto-completion for tags and names
    • Navigation to code symbols
    • Rename refactoring

    Other refactorings like Change Signature with Doxygen comments update, code generation and inspections may also be implemented.

This plan also includes various bug fixes and improvements (especially for C++ language support and refactorings in C++ code), as well as some additional features, that may enter later.

You are probably wondering about project models and Makefiles. The short answer is – no, these will not make it into CLion 2016.2. We still haven’t finished critical work around CMake support, and we are still investigating various options to provide support for other build systems/project models, or even allow opening sources without any build system set inside CLion.

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

Give CLion a try for free during the 30-day evaluation!

Your CLion Team
The Drive to Develop

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

39 Responses to CLion 2016.2 roadmap

  1. Barry Staes says:

    Nice to see it evolving. No Arduino love in the roadmap..?

  2. Diego says:

    Cool. Waiting for the QT (qmake) projects support.

  3. Roman says:

    Can I give my free subscription code to someone else?

    • Anastasia Kazakova says:

      Yes, you can either use it yourself for prolonging existing subscription or getting a new one (if you don’t have any) or share the code with a friend/colleague.

  4. Roman says:

    Looks like 2016.2 roadmap is more about making existing users happy , rather then attracting new ones (with additional platforms and build-systems support)

    • Dev says:

      A good thing!

    • Anton says:

      I’m happy that they announced many performance improvements, especially with the debugger. New features could be impressive, but the IDE, at least, must have polished the general ones: code editing and debugging.

  5. Olof says:

    Under cmake support I see that you are saying that you’ll add add_custom_target.

    Listing it here it seems as if there should be a larger implication that I as a cmake n00b probably is missing.

    Is it some sort of flexible external action launcher? If so, what are some things you think can be done? If not, what is it?

    • Roman says:

      Idea is the same as with Makefile targets. If you know Makefiles, you should understand targets, outputs, dependencies ect.

      I use add_custom_command and add_custom_target to:
      1) Run C/C++ code generators before C/C++ build. Common case is flex/bison and other parser generators.
      2) Supporting builds for new languages (other then C/C++) .

      • Anastasia Kazakova says:

        Thanks Roman for the answer. Indeed these are nice use cases for add_custom_target.
        In general it can be used to call any command. So there are plenty of use cases.

        I’d like to add also that add_custom_target is currently widely used for various projects like PlatformIO and others. In case of PlatformIO for example it works the following way: PlatformIO doesn’t use CMake, make or other built-in tools from IDE/host OS. It has own cross platform build system, own pre-built tool chains for specific development platform for cross compiling. When user presses “RUN”, then CMake just calls “platformio run”, which is equal for “Make” to “make build”. So from one side it works with all the specific provided by PlatformIO, from the other – there is a correct CMake project.

        add_custom_target is also used in the projects like and many others.

        The main problem is that currently the source files specified inside the custom target are not handled correctly as project files in CLion.

    • Marcus says:

      If you use add_custom_target to generate files in CLion today then you need to give it some “Reload CMake Project” love after the first build of the day (or any build that radically changes the auto-generated files) otherwise the parsing is all messed up.

      Also, any files auto-generated in this way (that exist off the CMAKE_CURRENT_BINARY_DIR directory) show up in the project tree off the root node which is a little odd (especially when you have hundreds of them like me)

      I’m assuming that 2016.2 will clean this lot up a little.

  6. Sebastian says:

    I didn’t read anything regarding Preprocessor support, are you planning to finally support the ## operator in CLion?

    • Anastasia Kazakova says:

      Such things are mostly included in the section for C++ language support bug fixes. Do you mean this We’ll consider it in our queue. Upvote to increase the priority.

      • Sebastian says:

        Thats exactly what I meant. Not having this implemented causes CLion to flag methods as unused because their usage is hidden by the ## operator and its also not possible to navigate to the method declaration or to find the definition through the “Find Usages” action. Also this is required for Google Test support:

        It would be great if you could achieve full preprocessor support in one of the next releases.

        • Anastasia Kazakova says:

          Thanks. We’ll try to fit these problems into the queue. Don’t forget to upvote the tickets to increase their priority.

  7. John says:

    I am super excited for 2016.2 now, for me you guys are hitting the killer features your customers have asked for (remote debug/add_custom_target and Doxygen). Thank you for taking your issue tracker votes seriously (it’s one of the things about how Jetbrains works that I think sets it apart from other companies in this space).

    Will be one of the first to try out a 2016.2 EAP.

  8. Vladeta Ljubisavljevic says:

    This will make one existing user happy :)

  9. Nick says:

    Please also start exploring the Linux on Windows capabilities that were anounced in MS build 2016. The option of using the native gcc compiler (instead of mingw), and creating/debugging ELF executables on windows would be amazing.

  10. RiaD says:


    Just wondering, are issues like CPP-4545, CPP-2394, CPP-1727 (the last one was created probably during private beta) are planned as “various bug fixed” or one shouldn’t expect them to be fixed in the next version?

    • Anastasia Kazakova says:

      C++14 is unlikely coming to 2016.2, and also some concerns about user-defined literals. We still have some bugs to fix that are more important than adding some new staff. However, we’ll take a look at this if have some free resources. Thanks for reminding!

      • RiaD says:

        Thanks for your answer

        Well, problem with this “new staff” is that it often bugs not only the places where these features are used, but up to all other code
        (When one error causes more and more errors)
        like literal is not supported -> type of variable detected wrong -> method calls are marked inaccessible.
        literal used 2 times in the statement -> most of the code is marked as unreachable
        As for me, basic editor features (like correct code highlighting) is the most important thing in any IDE

        Hope you’ll have some free resources then.

        • Anastasia Kazakova says:

          Thanks. You are right and we completely understand that. From the other side we have to have some priorities because of the lack of the resources. So these are in our plans but not in the first row.

  11. Olof says:

    Is the remote debugging the start of a plan to work towards supporting the remote toolchain? Or do you all think of it as a standalone feature?

    CPP-744 I think it is.

    • Anastasia Kazakova says:

      We’ll start with the attach to remote process. And then think about remote toolchain. Can’t estimate now how much will make its way to 2016.2. Most likely the first part for now. But we’ll see

  12. xing says:

    Glad to here that.
    Current version is still bunch of bugs, especially when it comes to macros.

    • Anastasia Kazakova says:

      Could you please specify which exactly problems do you mean? Are they submitted to our issue tracker?

  13. Pier says:


    When is 2016.2 scheduled to be released? Just wondering because I just purchased the license for a year :)

  14. Marek Lukáš says:

    I’m still waiting for a proper C project support. Even though CLion is called C/C++ IDE, it’s rather difficult to start a new a C project.

  15. Liam Coughlin says:

    C++ does not exist in my universe … any love for us place c developers ( maybe better c11 support, atomic.h for example…)

  16. Joel May says:

    Webassembly! Webassembly! Write code, compile, debug, navigate. Visual Studio is default IDE for C++ on Windows, Xcode is default on Mac. CLion could be default Webassembly IDE.
    I tried setting up CMake in CLion for webassmbly myself, but I was going down the infinite rabbit hole and gave up. While waiting for webassembly to become fully available, you could also support emscripten.

Leave a Reply

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