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

Hi,

Today we are glad to announce that the first CLion 2017.1 EAP build (171.2613.3) is available for download.
Clion_2017_1EAP@2x_img
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.

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:
auto_intention

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:
auto_return

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:
    base_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

regex_log_viewer

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:
editor-latency-linux-xml
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:
linux_sourcekit@2x
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
JetBrains
The Drive to Develop

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

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

  1. Matthew says:

    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?
    https://youtrack.jetbrains.com/issue/CPP-870

  2. Konstantin Isakov says:

    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:

      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.

      Regards,

    • mbalabin says:

      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: https://youtrack.jetbrains.com/issue/CPP-7166) 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:

        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:

    Great improvements! Any idea when there will be a fix for this debugging issue: https://youtrack.jetbrains.com/issue/CPP-6550
    Not being able to view contents of an array during debugging is a deal-breaker!

    • Anastasia Kazakova says:

      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:

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

    • Anastasia Kazakova says:

      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:

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

  6. Mikhail says:

    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:

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

  7. Roman says:

    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:

      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:

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

  8. PM says:

    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:

      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:

        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. https://github.com/FedoraSwift/fedora-swift2

        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/liblldb.so.3 has to be present for debugging to work, and on my fedora 25 builds it was creating a liblldb.so.4.0.0 file instead. A quick symlink sorted that out.

  9. Ivan says:

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

    • Anastasia Kazakova says:

      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:

    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:

      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:

    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 (https://youtrack.jetbrains.com/issue/CPP-988#comment=27-950068)

    • Anastasia Kazakova says:

      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:

      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:

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

  12. Alexander says:

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

  13. Danylo Bilyk says:

    Any chance to see something from issues below in next release?
    Issues actually originated in 2014 year!
    https://youtrack.jetbrains.com/issue/CPP-480 Single file compilation
    https://youtrack.jetbrains.com/issue/CPP-870 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:

      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:

    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.

    Name.cpp:
    void Name::foo() const Written up and mentioned in CPP-6094
    https://youtrack.jetbrains.com/issue/CPP-6094

    http://en.cppreference.com/w/cpp/language/member_functions#const-.2C_volatile-.2C_and_ref-qualified_member_functions

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

  15. Mike says:

    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:

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

      • Mike Mitterer says:

        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:

          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

Leave a Reply

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