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):
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+Don Windows/Linux,⇧⌘Don OS X. - From the generate menu (
Alt+Insertin Windows/Linux,⌘Non OS X):
- 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:
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
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.
We do work on debugger continuously and many fixes were included in the previous EAP builds. Hope to have more soon. Thanks for support!
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.
It’s not about GDB of course, but about CLion supporting this at its side. We hope remote debug will come soon.
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…
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.
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.
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.
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.
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.
Put it here: https://youtrack.jetbrains.com/issue/CPP-5934. So you can follow.
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.
Yes, we are considering this (https://youtrack.jetbrains.com/issue/CPP-812, https://youtrack.jetbrains.com/issue/CPP-3159)
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.
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.
Thanks. We’ll consider the option when come to this feature.
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.
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.
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?
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.
thanks a lot, we’ll investigate
Temporary switched back to 1.2.4.
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).
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.
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
Looks like it’s the same as this one: https://youtrack.jetbrains.com/issue/CPP-5894. Follow to get the updates.
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.
We can check if you provide some sample to reproduce. Feel free to share in our tracker: https://youtrack.jetbrains.com/issues/CPP
the issue was fixed in latest update. Thanks