Clion logo

The CLion Blog

A Cross-Platform IDE for C and C++

Early Access Program News

CLion starts 2017.1 EAP: convert variable type to auto, zero latency typing and various fixes


Today we are glad to announce that the first CLion 2017.1 EAP build (171.2613.3) is available for download.
You can install it side by side with your current stable CLion version, no active subscription required.

Download CLion 2017.1 EAP

Short summary:

Upd. More C++14 support (generic lambdas, variable templates and generalized lambda captures) is also included into CLion 2017.1 EAP.

Upd2. Precompile headers and -include support is added to CLion 2017.1 EAP.

Upd3. CLion EAP introduces MSVC compiler support.

Upd4. Disassembly view in debugged when sources and Catch unit test framework support are now available in CLion 2017.1 EAP.

Closer to Almost Always Auto

Using auto type for variable declarations is a powerful feature of modern C++ that makes the code less verbose and thus more readable. It also obliges you to initialize the variable. Herb Sutter once wrote an interesting article in his blog on AAA (Almost Always Auto) style, where he tried to analyze when the use of auto is justified and when it’s not. As we do support many ideas shared there and we’d like to help CLion users to modernize their C++ code, we’ve introduced this new intention action which converts variable type to auto:

While this is still a work in progress, we will also consider the opposite action – replacing auto with an appropriate variable type (CPP-8555).

This EAP also includes support for the auto return type (CPP-4321), which means more accurate code analysis, correct type inferred and shown in the Quick Documentation pop-up and code completion:

Quick Documentation

Quick Documentation pop-up (Ctrl+Q on Linux/Windows, F1 on macOS) combines lots of information about the code entity under the caret. For macros, it shows information about macro replacement, as well as macro substitution. For variables, it includes type information, even providing you with an inferred type for variables declared as auto. It shows signatures for functions, along with links to the referenced types, and much more, even including Doxygen-styled documentation preview and code comments.

In this build we’ve worked on polishing the Quick Documentation pop-up:

  • When comments are placed inside the code, Quick Documentation now includes both: type information and the comment
  • If the code entity under the caret doesn’t have any documentation comment, but the parent entity does, then Quick Documentation will show the parent documentation:

Project model

Project model is becoming more user-friendly with a couple of useful fixes:

  • Renaming a project no longer breaks existing run configurations
  • Obsolete not-modified run configurations, and run configurations for deleted targets, are now removed automatically
  • For existing CMake projects, the project name in CLion is taken from CMake’s PROJECT_NAME on first opening

Besides, when opening a project in CLion for the first time, an executable run configuration is pre-selected now. Previously, it was a Build All configuration which may miss an executable to run and thus confuse users.

VCS Log Viewer

An updated VCS Log Viewer provides you with a few new options to tune search over commit messages there:

  • You can use regex
  • You can choose whether to make the search case sensitive


Zero latency typing

While you type in the editor, the IDE is always doing lots of things in the background to provide you smart features on the fly, like completion, code analysis, formatting, etc. Wouldn’t it be great if typing performance weren’t visually affected by this fact? Ideally it should be comparable to that provided by a simple, code-agnostic text editor.

Some time ago Pavel Fatin, a developer at JetBrains, researched editor latency. Based on his findings, he implemented an experimental feature for IntelliJ IDEA (and the whole IntelliJ Platform) called zero latency typing. In a nutshell, his solution reduces the number of editor repaintings and performs them in a smarter way. The results are impressive:
So today, after almost 6 months of extensive testing, we are enabling zero latency typing as the default setting in all IntelliJ-based IDEs, including CLion.

Dvorak layout support and more

If you’re more used to Dvorak layout in macOS than QWERTY, you’ll be glad to know that keyboards shortcuts like ⌘/, ⇧⌘], ⇧⌘[, ⌘+ and others are now working properly with it (JRE-172).

Besides, this EAP addresses an issue with Korean, Chinese and Japanese keyboard layouts on macOS.

Code analysis fixes and other improvements

There are more bug fixes and enhancements introduced in this EAP build:

  • Incorrect Call to pow is ambiguous warning for GCC 6.2 was removed (CPP-8543)
  • Incorrect Too few template arguments warning was fixed (CPP-7150)
  • CLion now doesn’t suggest to reduce TRUE macro to ‘true’ for pure C code
  • CLion now doesn’t suggest to make static or friend functions pure virtual
  • Hidden functions from the base class are no longer suggested in the completion
  • Settings Repository plugin is finally bundled into CLion

Swift plugin: SourceKit inspections and intentions

We are glad to announce that SourceKit inspections and intentions are now available in the Swift plugin for CLion both on macOS and Linux:
Internally, the Swift plugin for CLion uses the SourceKit in-proc implementation.

Note that since the full support for reading Swift modules on Linux is not available yet, there could be issues with SourceKit integration in projects with complex dependencies. If you experience such problems, please report them in a sub ticket here.

Besides, we’ve added a New Project template for Swift, that allows you creating a new Swift project with ease (minimal working context is created automatically by CLion).

NB: We are very much looking forward to your feedback in order to help us create a tool that you will enjoy using on everyday basis. So if you do use CLion as a Swift IDE on Linux, let us know about your use case, your needs and your experience with CLion.

That’s about it. The full release notes are available here.
Stay tuned and don’t miss more exciting features and valuable fixes coming soon.

Download CLion 2017.1 EAP

The CLion Team
The Drive to Develop

Comments below can no longer be edited.

51 Responses to CLion starts 2017.1 EAP: convert variable type to auto, zero latency typing and various fixes

  1. Matthew says:

    January 25, 2017

    More nice improvements, thank you!

    Is Ninja support still on the roadmap, it was mentioned a couple of releases ago but I have not heard anything since then?

    • Anastasia Kazakova says:

      January 25, 2017

      It’s planned for one of the 2017.x, not sure when it comes however.

      • Matthew says:

        January 25, 2017

        Ok, thanks for the reply.

  2. Konstantin Isakov says:

    January 25, 2017

    It feels that CLion developers prefer working on features they find fun to develop but steer clear from hard and boring stuff, with the end result of having some of the C++17 things already working, but with some core language features still misinterpreted/unsupported. When the initial CLion alpha was released, I asked for correct handling of #include statements inside namespaces (CPP-1100). More than two years passed, and I’m still waiting, even though the hopes are low at this point, as I can clearly see that fun new experimental C++ features are more attractive for the developers than getting the things which have been there for decades right.

    I wish JetBrains all the luck, I’m sure it’s a fun place to work at, but just as a heads-up, this guy over here is still not your customer.

    • Anastasia Kazakova says:

      January 26, 2017

      Hello Konstantin,

      Previous standard features are important, of course, and could be even more important than the new standard features, as new one may rely on an old one. So we try keeping the balance and fixing issues/implementing support for all standard. Thank you for pinging about CPP-1100. We’ve check why it was postponed and maybe we could put it to the current queue.


    • mbalabin says:

      January 31, 2017

      I agree with Konstantin. Supporting new language features is important and fun, but you should not forget about core IDE functions. I can do my work if «convert to auto» is not available, but if a debugger is not working correctly (like, incorrectly displaying contents of my vectors: then I am in deep trouble. Flawless debugging is a must for a descent IDE. Right now debugging is probably the only essential area where Clion experience lags behind Visual Studio. You have done very solid improvements in this area during 2016 and I am sure that all the developers would be grateful if you keep that pace in 2017.

      I am aware that in many cases the source of a problem lies in external tools (bugs in gdb, deficiencies in libstdc++ printers). If JetBrains could devote a fraction of its resources to improving external tools (or at least pushing for specific improvements), that would also be fantastic.

      • Anastasia Kazakova says:

        January 31, 2017

        Thanks for reminding about this problem.

        You are right that debugging experience is essential for the IDE. But we are not in the situation when we either put our resources into language support or into debugger. These resources are separate and we do our best to work in all main directions at once.

        Regarding this particular problem, we keep an eye on it, but not started it yet, as it requires quite a lot of changes (and longer investigation) and we have several more important problems around debugger that would like to address before (this btw also includes contributing into GDB/LLDB with some bug fixes). We’ll definitely come to this particular problem a bit later.

  3. Asmo says:

    January 25, 2017

    Great improvements! Any idea when there will be a fix for this debugging issue:
    Not being able to view contents of an array during debugging is a deal-breaker!

    • Anastasia Kazakova says:

      January 26, 2017

      We agree that’s important. We’ll see if we can address it in the nearest future.
      Have you tried the workaround btw?

  4. Evgeniy says:

    January 25, 2017

    What about Valgrind support? It’s one of the most voted feature requests for some two years as for now…

    • Anastasia Kazakova says:

      January 26, 2017

      Mostly likely not coming to the 2017.1, but we keep considering it for every new version and it’s indeed one of the top voted request. Maybe later in 2017 we can address it as well.

  5. Oleksii Vilchanskyi says:

    January 25, 2017

    Are there any plans to support cmake server mode introduced in 3.7?

    • Anastasia Kazakova says:

      January 26, 2017

      We are currently investigating it and playing around internally. When get some results, we’ll check when and how it can be supported in CLion. Follow the updates under

      • Olof says:

        January 26, 2017

        Would that be a way to support remote compilation/remote tool chain?

        • Anastasia Kazakova says:

          January 26, 2017

          This task is actually wider I believe. Anyway, we’ve just started with looking at CMake server, so I can’t promise you anything particular at this point.

      • Oleksii Vilchanskyi says:

        January 29, 2017

        Thank you.

  6. Mikhail says:

    January 26, 2017

    On screenshot “Description copied from: fn” does not show which base class it was copied from. How about “Description copied from: Base::fn”

    • Anastasia Kazakova says:

      January 26, 2017

      Probably, it makes sense. However, you can click into fn and navigate to it’s quick doc (and then back).

  7. Roman says:

    January 26, 2017

    Should we probably use auto&& for non-const locals? Or this is considered unnecessary optimization?

    float var0 = 41.f;
    int var1 = f();

    to :
    auto&& var0 = 41.f;
    auto&& var1 = f();

    P/S (please provide disassembly view in Clion to explore what will be generated for this code sample 🙂

    • Roman says:

      January 26, 2017

      It turned out C++17 requires return value optimization by default. So even with -O0 you will never see a difference between auto and auto&& when initializing locals with temporaries. So probably one should use auto&& only for non-copyable objects.

    • Anastasia Kazakova says:

      January 26, 2017

      Disassembly view is under development currently. Hope to get it done soon.

  8. PM says:

    January 27, 2017

    Hi. I have been using CLion for Swift development on Linux. The SourceKit inspections are very welcome, but the biggest problem by far is that C libraries imported via Swift modules (i.e. module maps as part of a Swift Package), are not resolved by CLion. I suspect the majority of people using Swift on Linux will be using the Swift Package Manager and will be using C libraries, so currently CLion is really only a single step up from a text editor, rather than the thousands of steps up that I’d usually expect from a JetBrains IDE. My debugger doesn’t work, either.

    The project I’m working on is an open source, although I haven’t made it public yet. If you need a project to replicate these kinds of issues, let me know and I can send it.

    • Anastasia Kazakova says:

      January 30, 2017

      Thank you for your feedback.

      Have you tried this temporary workaround?

      Would be great is you can share the link to the project, also Linux version and Swift toolchain number used (maybe just a screenshot from File | Settings | Build, Execution, Deployment | Swift settings). Could you please provide more details also on debugger problem and maybe it’s possible to get debugger logs as described here?

      • Tim Hawkins says:

        February 6, 2017

        What flavor of linux are you using?

        I created a set of buildscripts for fedora that builds swift support, and the debugging seems to work with ClIon.

        If you check the releases there you can see a screenshot of the swift debugger working with cLion.

        I did find that the file [swift root]/usr/lib/ has to be present for debugging to work, and on my fedora 25 builds it was creating a file instead. A quick symlink sorted that out.

    • Scellow says:

      April 13, 2017

      I’m also looking for this, i created an issue here:

  9. Ivan says:

    January 30, 2017

    Is the general build system API in the 2017 road map?

    • Anastasia Kazakova says:

      January 30, 2017

      We are considering the work in that direction in 2017. However, not sure if it will be a general API or just another (Makefiles?) build system support. Still under discussion and won’t come to 2017.1 for sure.

  10. Olof says:

    January 31, 2017

    It appears as if the typing latency is much improved even though I’m using IdeaVIM 0.48 which apparently doesn’t have some zero latency feature that is in 0.48.4.

    How will the IdeaVIM zero latency feature help and what is it?

    • Anastasia Kazakova says:

      February 1, 2017

      IdeaVim 0.48.4 simply uses the same API as the whole platform and it works in the same way, as described here in the blog post. So if you enjoy it, you;d better switch to v0.48.4 to benefit from it in IdeaVim as well.

  11. Anton says:

    February 2, 2017

    Zero latency typing?
    Try to open any cpp file which has at least 1000-2000 lines (if it includes WinAPI headers, it is even better), place the caret between the functions and hold the Enter key. Then do the same with Backspace. I have a lot of freezes with that scenario. Already reported more that a year ago (

    • Anastasia Kazakova says:

      February 2, 2017

      This problem is currently under investigation. But it’s not related to Zero latency, that is about a different thing. Both affect the editor performance, of course, but in various ways.

    • Anastasia Kazakova says:

      February 2, 2017

      Anyway, thanks for reminding, I’ll check what’s the current state and if there is any progress or update in the issue. We’ll try to provide comments/updates in the actual ticket.

    • Anastasia Kazakova says:

      February 2, 2017

      By the way, have you tried 2017.1 EAP? Our users are reporting significant improvements with it under this ticket.

      • Anton says:

        February 2, 2017

        I do. And yes, I see improvements. Thank you for your reply.

        • Anastasia Kazakova says:

          February 3, 2017

          Thank you for checking!

  12. Alexander says:

    February 5, 2017

    There was a possibility to view the assembler listing in Clion 2017.1?

    • Anastasia Kazakova says:

      February 6, 2017

      It is going to come to 2017.1, but not yet there. Follow the updates.

  13. Danylo Bilyk says:

    February 14, 2017

    Any chance to see something from issues below in next release?
    Issues actually originated in 2014 year! Single file compilation Ninja CMake generator
    Work on huge projects becomes pain in an …
    Also there is a several ninja related issues and as result of this users’ votes are split between them.

    • Anastasia Kazakova says:

      February 14, 2017

      Ninja generator support may come in 2017, but most likely not in 2017.1. Currently CLion only can parse the Makefile-generator output, NMake will come with MSVC support. And Ninja is likely to follow.

      Regarding the single file compilation, could you please share your thoughts on the following:
      A file can be in several targets, and each target is in different configurations. In which target/configuration should a file be compiled?

      The thing is that CLion doesn’t build itself, it simply runs cmake –build . command. So the task is not that clear for now. We are thinking about it but haven’t decided anything yet. So your thoughts are much appreciated.

  14. Mattias Fornander says:

    February 16, 2017

    Love all the new stuff but I too are concerned that core C++11 features are not fixed before C++14 are worked on. Most of my source files are flagged red on each line after I use ref-qualified member functions in my cpp files. This makes this IDE that I’m paying for almost useless.

    void Name::foo() const Written up and mentioned in CPP-6094

    Please make all of C++11 usable before moving on to shiny new features…

    • Anastasia Kazakova says:

      February 17, 2017

      Thanks for the reminder, we’ll check what’s going on there.

  15. Mike says:

    February 16, 2017

    I’m using CLion since it’s early days and I really like it! But what really annoys me is that it’s not possible to open multiple independent modules in CLion. Most of the time I have 2 or more CLion instances open. All other Jetbrains IDEs support multi module project – only CLion is missing this feature. A “root” CMakeLists is not an option if the modules are independent of each other.

    • Anastasia Kazakova says:

      February 17, 2017

      Why can’t you simply open several projects in CLion? Or do you need them in one window?

      • Mike Mitterer says:

        February 18, 2017

        Yea, I want them in one window – like it is in all your other IDEs. I have another example: My daughter studies informatics and for their homework they use CodeBlocks. I recommended here CLion (she knows PyCharm already) – They have a lot of small projects as homework and usually they copy things from one project to the other or they look up things they already made in a previous homework. No problem with CodeBlocks or Eclipse – a big problem with CLion. She ended up with x different windows. I have three screens so its somehow acceptable but she has only one… – Very annoying. She went back to CodeBlocks…

        • Anastasia Kazakova says:

          February 20, 2017

          With small projects you can put them under one CMake.
          However, I do understand the request. The problem is that we rely on CMake heavily for now and it requires some major changes to have several independent CMake projects in one Window. We do consider this feature for the future, but have others for now that are of higher priority. But that’s for your feedback anyway! Follow the updates

  16. Asm says:

    March 1, 2017

    do you plan to add full asm support, similar to this plugin for VS ?

    • Anastasia Kazakova says:

      March 1, 2017

      Do you expect some exact features? Or the whole experience?

      The main idea of it for now is to get disassembly view in debugger. All the rest may be considered later.

  17. bug says:

    June 6, 2017

    Error:Executable is not specified

    cmake_minimum_required(VERSION 3.7)

    set(CMAKE_C_STANDARD 99)

    set(SOURCE_FILES main.c first.c)
    add_executable(untitled ${SOURCE_FILES})

    • Anastasia Kazakova says:

      June 6, 2017

      When do you get this error?

  18. renan says:

    October 14, 2017

    any plans for swift 4.0 support ?

    • Anastasia Kazakova says:

      October 16, 2017

      Swift 4 is already appeared in AppCode, and thus in the corresponding CLion’s plugin. The progress of Swift 4 support can be tracked here:

Discover more