CLion 1.5 EAP: new code generation possibilities and improved auto-import

Posted on by Anastasia Kazakova

Hi,

Previous CLion EAP build included variadic templates support and was called experimental, since we were not sure about the quality of the support and the performance. After a week we see that though some issues and regressions are still present, the overall impression is positive, so we decided to push variadic templates to the upcoming release.

Today another EAP build is available for download, and its main focus is code generation.

Generate definitions and more

CLion helps you implement your ideas at the speed of thought with the code generation features, getting routine and mundane tasks out of your way. The set of features includes Override/Implement, generating constructors/destructors and getter/setter functions, ‘Surround with’ and Live Templates, and create from usage possibility.

Override and Implement actions generate stubs for virtual member functions from any of base classes. Having a couple of requests related to these features, we now added generate definitions (Shift+Ctrl+D on Windows/Linux, ⇧⌘D on OS X), that (we believe you can guess!) generates definitions for existing declarations. If the caret is placed inside the class, then the definition will be located right there in-place. In other cases, CLion will ask you about possible destinations (if several are possible):
generate_definitions

By the way, Override/Implement features now work in the same way, asking for a destination (if several options are available) or generating code in-place for the caret located inside the class. That means if you want the function to be generated in a header file – locate the caret in that class in your header file, and if you want it in the source file – execute action there.

Generate definitions can be called in various ways:

  • By pressing Shift+Ctrl+D on Windows/Linux, ⇧⌘D on OS X.
  • From the generate menu (Alt+Insert in Windows/Linux, ⌘N on OS X):
    generate_menu
  • As an intention action (Alt+Enter) – the only difference from the above is that intention action can generate only one definition at a time, while other options allow you to generate several function definitions at once.

This also makes Implement action more logical and consistent with other JetBrains IDEs – now it just overrides pure virtual functions from base classes.

Try this new feature and let us know what you think!

Auto-import

Another big change introduced in this EAP build is an improved auto-import. Import assistance in CLion allows you to add includes automatically when non-imported symbol is met. Just press Alt+Enter and the include statement will be added, no need to move cursor from the current position and interrupt your editing session.
Some unexpected headers were suggested for STL symbols before. In this EAP build we’ve implemented special heuristics to solve the problem for C++ files and STL symbols, and we encourage you to evaluate the changes:
auto_import

Besides, this build addresses the following problems:

  • When the code generation is called or Extract Function refactoring is invoked, the enum types arguments and return types are now passed by value, not by reference (CPP-5781).
  • The bug with generating incorrect implementation for functions with default value is fixed (CPP-1889).
  • The bug with Rename that didn’t update non-code usages in case refactor preview was called is now fixed (CPP-5471).

As usual, full release notes are available by the link. Download the build 144.4199 from the confluence page. Unfortunately, due to some technical issues patches are not available this time. We are sorry for the inconvenience.

Read about all new features coming to the next release on Preview Next Version page on our site.

The CLion Team
JetBrains
The Drive to Develop

Comments below can no longer be edited.

29 Responses to CLion 1.5 EAP: new code generation possibilities and improved auto-import

  1. Anton says:

    February 18, 2016

    Guys, you did a great job and the current features we have are simply fantastic. But please, fix the debugger integration. Without a working and responsive debugger, CLion can’t be used as a full-featured IDE. For almost a year in my everyday work, I periodically fallback to another IDE. It’s not as cool and convenient as CLion, but it’s very fast and just work as it should. You have almost reached a 1.5 milestone and IDE should have a working debugger at this point.

    • Anastasia Kazakova says:

      February 18, 2016

      We do work on debugger continuously and many fixes were included in the previous EAP builds. Hope to have more soon. Thanks for support!

    • Leo says:

      February 20, 2016

      I second that. What I also do not fully understand is why the integrated debugger component cannot work with a remote target. Its not like gdb would behave so much different connecting to a gdb server than locally.

      • Anastasia Kazakova says:

        February 20, 2016

        It’s not about GDB of course, but about CLion supporting this at its side. We hope remote debug will come soon.

  2. Yury V. Zaytsev says:

    February 19, 2016

    I see a lot of progress on the variadic front, hopefully the regressions will be killed before release, and maybe finally will come the time of C++14. Yay! Before CLion got support for variadics, a lot of inspections were missed just because it didn’t understand the code, but now it does, and it currently applies C++11 profile even with -std=c++14, which makes things redder than ever…

    On a related note, I find it really to be a huge pain to re-type the error messages shown upon pressing Ctrl+F1 when reporting bugs, especially if the long / complicated types are involved. Is there anything that can be done about it? Some magic to copy the messages to clipboard directly? It’s just so depressing to rekey all this stuff…

    • Anastasia Kazakova says:

      February 19, 2016

      Thanks for your support. Yes, many issues are already fixed and many are in progress currently.

      Regarding the messages, I’m afraid no, except for workaround – running code analysis on a file (run inspection by name or just all inspections on a file via Code | Inspect Code…) and find proper one in the list afterwards.

  3. Ivan says:

    February 20, 2016

    I have also noticed that updating symbols on the project takes about as long as building them from scratch. At least I observed this on heavily templated projects.

    • Anastasia Kazakova says:

      February 20, 2016

      It depends on the prj complexity and what you do to invoke updating symbols. However, if you could share a CPU snapshot (https://intellij-support.jetbrains.com/hc/en-us/articles/207241235-Reporting-performance-problems) and IDE logs, we’ll investigate. Submit to our support team, pls.

      • Ivan says:

        February 20, 2016

        You can replicate the bug with this open source project:

        https://bitbucket.org/gtborg/gtsam/

        Build symbols first without any cmake flags and then add -DCMAKE_BUILD_TYPE=Release to the cmake flags to replicate the problem.

        • Anastasia Kazakova says:

          February 20, 2016

          Just tried on this project:
          building symbols from scratch – 17 minute
          after changing flags – 10 minutes
          simply call cmake reload – 10 minutes

          The thing is that flags editing causes cmake rerun, that in turn causes symbols update. Just the same as if you call cmake reload.

          The problem I see here is that updating symbols should go faster with no changes, especially taken into consideration that this flag is ignored, because CLion by design generates all four configurations on cmake run to provide you a possibility to quickly switch this context in the editor (so the resolve works in either Release, or Debug, or MinSizeRel, or RelWithDebInfo configurations. Needs further investigation, I’ll log into tracker.

          • Anastasia Kazakova says:

            February 20, 2016

            Put it here: https://youtrack.jetbrains.com/issue/CPP-5934. So you can follow.

          • Olof says:

            February 23, 2016

            It would be nice if that could be controlled somehow. We only ever use debug and release so paying the price for the other two is not needed.

          • Olof says:

            February 24, 2016

            This might be interesting to look at from a usage perspective. I reload the cmake files 10-20 times a day, but I rarely switch between Debug or Release. Probably just a few times a week.

          • Olof says:

            February 24, 2016

            Oh, and to finish my thought.

            A check button that said to generate configurations for all four when reloading cmake, or only for the current and then to generate configurations when changing to a different configuration, would be a nice simple and clean solution.

            • Anastasia Kazakova says:

              February 24, 2016

              Thanks. We’ll consider the option when come to this feature.

  4. Roman says:

    February 20, 2016

    Code completion does not work in this build in most of cases for my project. Tried re-parsing project, and invalidating caches. Didn’t helped.

    • Roman says:

      February 20, 2016

      Oh, I got it: looks like it now takes ~ 20 seconds to show list of suggestions, used to be less then one second.

      Unfortunately, when you got smarter, you become slower.

      • Anastasia Kazakova says:

        February 20, 2016

        This looks like a bug. Is it reproducibale since this EAP only? Could you please share the prj to reproduce or at least got a CPU snapshot with such completion and submit to our support?

        • Roman says:

          February 21, 2016

          It used to be better on previous EAP build. But with new build auto-completion works randomly: sometimes it shows pop-up instantly, sometimes I have to wait ~30 seconds for the same code.

          I’ve captured CPU snapshot during ~20 seconds waiting for pop-up. It appeared at the end. https://youtrack.jetbrains.com/issue/CPP-5937

          top shows 30% CPU utilization when I wait for auto-completion.

          • Anastasia Kazakova says:

            February 21, 2016

            thanks a lot, we’ll investigate

        • Roman says:

          February 21, 2016

          Temporary switched back to 1.2.4.

  5. David Weisgerber says:

    February 26, 2016

    I love working with CLion at the moment using version 1.2.4. However, there is one major use case where I cannot use it at the moment:
    There is no Visual Studio Compiler/Debugger integration for Windows. I hope you can fix this soon as I need this for most of my projects.
    In addition, it would be nice to have some degree of Qt support (specially for the debugger).

    • Anastasia Kazakova says:

      February 26, 2016

      MSVC is currently out-of-scope for CLion, since we have ReSharper C++, an extension for VS, that supports it.
      As for the Qt debugger – we have this feature request https://youtrack.jetbrains.com/issue/CPP-605. Upvote to increase the priority. And if you expect more, log your requests into our tracker.

  6. Lectem says:

    March 5, 2016

    Sadly I still have issues with auto-import, using mingw-w64. for example map/unordered_map/vector will still try to include c++/…/bits/…h

  7. Sebastian says:

    May 24, 2016

    I’m no longer getting “add method” suggestion – the popup menu only contains the “Cannot resolve” option. I’ve invalidated the cache and reloaded cmake project but nothing changed. Using 2016.2 EAP on arch linux.

    • Anastasia Kazakova says:

      May 24, 2016

      We can check if you provide some sample to reproduce. Feel free to share in our tracker: https://youtrack.jetbrains.com/issues/CPP

      • Sebastian says:

        May 30, 2016

        the issue was fixed in latest update. Thanks

Subscribe

Subscribe for updates