Hello, Habr! Many are already starting to prepare for the New Year holidays, to buy gifts, someone is planning a trip for the long New Year holidays. And at JetBrains, itās still a hot time for us to release product releases. Today I am in a hurry to share with you the news about the recently released release of our cross-platform development environment for C and C ++ - CLion 2019.3.
The main goal of this release was, however pathetic it may sound, quality. We decided to focus on the problems that have been bothering our users for a long time - first of all, the productivity and responsiveness of the editor, and secondly, bugs, imperfections and very popular, but missing features.
To begin with, briefly about the most important thing in this release:
- Improvements to the editorās speed and responsiveness, primarily auto-completion implemented in our engine based on Clangd.
- Ninja generator in CMake, default CMake settings and other design model improvements.
- Updates in integration with debuggers.
- New action for switching between header and sour files.
- More accurate code analysis: a new check for virtual functions, as well as spell checking in CMake and in Doxygen comments.
- Support for concepts from the C ++ 20 standard.
- Code coverage metrics.
- WSL2, Microsoft's formatting and naming conventions, VCS support updates, and more.
Weāll talk in more detail below, but if you are ready to try it now, then go in and download the build from
our website . As usual, a free trial for 30 days is available.
Editor performance
Judging by the statistics that many of our users agree to send us, the most commonly used action in CLion is
auto-completion . It was on him that we decided to focus in this release to make it more responsive. To do this, we added one more, based on Clangd, to the autocomplete providers already existing in the IDE. The bottom line is that all suppliers work in parallel, and as soon as the first results are ready, CLion displays a drop-down list of options, continuing to load other options as needed.
Of course, we wanted to understand whether such a hybrid approach provides benefits. The measurements showed that on simple projects the speed of the CLion vendor and the Clangd-based provider do not differ much. But on complex projects such as LLVM, Qt, Boost, Eigen, the first hundred results from Clangd appear much faster. Judge for yourself:
Read more about measurements in a separate
article on the CLion English-language blog.
Among other significant improvements, it is worth noting the platform acceleration of the IDE launch time. It was achieved by parallelizing many processes at the start, reorganizing the classes loaded at the start, and optimizing font loading on macOS. The specific numbers to accelerate depend on the settings of the environment, car, platform and other factors.
In CLion, to our great regret, there are still user interface hangs. We try to group them according to the original problem and fix one problem after another. So, in this release we fixed the freezes in cases of an open Usages View, when switching to a declaration, when renaming the
#include directive, when using bread crumbs and safe delete, as well as in other cases. User interface suspensions remain the most urgent problem for us, so we will definitely continue this work in future releases.
And finally,
Rename acceleration refactoring . This refactoring can rename not only the use of the name in the code, but also in string literals and comments. But this is not always necessary, and the search for the name was carried out before the IDE user indicated which particular uses would be renamed. This led to long delays in finding a popular name. Now you can first select a search only by code, and only then start the search itself. To do this, go to Settings / Preferences | Editor | General | Refactorings must be disabled āEnable in-place modeā. In this case, when refactoring is called (Shift + F6 by default on Windows / Linux, ā§F6 on macOS), CLion will immediately open the Rename dialog, where you can specify the search parameters:
CMake Design Model Improvements
Here, many of you must have been waiting for the announcement of support for Makefiles. But so far only a
semi-automatic approach to their integration through the compilation database is available. More native support is still under development, but in this release cycle we have made great strides and we have every chance of showing new support for the next release 2020.1, around the end of March 2020.
But we made the long-awaited opportunity to support CMake - the ability to specify any CMake generator, including the
Ninja generator so much expected by users! Previously, we used Makefiles and similar generators, since we parsed the resulting files (more precisely, they were
-G āCodeBlocks - Unix Makefilesā , and on Windows
-G āCodeBlocks - MinGW Makefilesā and
-G āCodeBlocks - NMake Makefilesā ) Now you can specify any generator in the CMake profile in CLion:
This is possible only when using CMake version 3.15 and higher, as it is implemented through the CMake File API, and works on all platforms, remotely, for WSL / WSL2.
I note that such generators as Xcode and Visual Studio are multi-generators, that is, they generate files for all types of assemblies (Debug, Release, etc.), but CLion will only use the assembly type specified in CMake profile.
This release also introduced
default CMake settings . This means that for all new projects in CLion, you can use the same predefined settings, such as the CMake generator or the directory for generating CMake. Settings can be specified in File | Other Settings | Settings for New Projects ...
Of the important improvements to the CMake project model, it is still worth pointing out the ability to reload valid configurations, even if other invalid ones are present in the project. This can be useful if you have configured several remote configurations that are currently unavailable, but want to reload at least local configurations.
Debugger Integration Update
In debuggers, we decided to fix the problems and deficiencies that concern our users the most. Firstly, CLion now reads
.gdbinit / .lldbinit from the project directory . This is useful if you want to customize some debugger settings or add pretty printers, but only for a specific project. Previously, you had to specify these settings in the debugger configuration files in the user directory. Now you can configure these parameters specific to the project. But for this to work, you need to enable this behavior in the debugger itself in the settings at the user directory level (read how to do this for
GDB and how to
LLDB ).
Integration with LLDB is available on Linux and macOS. In the new release, we upgraded the built-in LLDB to version 9.0, and at the same time globally reviewed all the built-in pretty printers. Thanks to this, the performance of standard containers on both platforms has improved significantly. Detailed comparatives can be found on our
English-language blog . It is worth noting that on the macOS platform, the
libc ++ library handles much better than
libstdcxx . This seems to correspond to the popularity of these libraries on this platform, but if you are using
libstdcxx on macOS, please tell us more about such cases in the comments.
CLion now has
several options for remotely working with a project and debugging. From the completely remote option, when both the assembly and debugging of the project occur on a remote machine, to the options where only the project is debugged remotely. That's it for the second case, we added another configuration to CLion -
Remote GDB Server . Unlike the long-standing
GDB Remote Debug (yes, we didnāt have any names, we agree), in the new configuration, CLion builds the project itself (perhaps you need to configure cross-compilation settings), download the executable file to the remote machine, and runs your program under the specified gdbserver. The old configuration is now more suitable for complex options, when the code is on one machine, assembly on the second, and debugging on the third. Or if cross-compilation is not possible.
Go to header / source files
Yes it did! We finally added a separate action to switch between header and sour files. What is the main difference from the old platform
Go to Related Symbol ? The fact is that, as a common platform action,
Go to Related Symbol tries to be very accurate and choose one the most correct option. This is both long and not always correct in the case of C ++. The new
Go to Header / Source action behaves differently:
- If within 500 ms there is no one single correct option, then a drop-down list of suitable options appears, from which the user can select the most suitable.
- If the user has already navigated from this file, the file where he was navigating to will be at the top of the list.
- Further in the list will be files from the same directory with the same name.
- And then the search results for matching declarations and definitions will go on.
It is worth noting the search feature (as our users have already met with it) - the search is now conducted on directly included / inclusive files. This is a time limit that is necessary so as not to confuse characters with the same name from different targets.
Code analysis
A new check has appeared in the CLion code analyzer. It catches situations when virtual functions are called from constructors or destructors. Why this is bad has already
been discussed a lot . Now CLion warns of such cases:
Spell Checker is an integral component of an integrated development environment. We all make spelling mistakes, and then itās hard for our colleagues to read the code and comments. Therefore, it is good when the IDE highlights such errors. In this release, we have included spellchecking in CMake files and Doxygen format documentation comments:
Less spelling mistakes - more readable code!
Concepts from C ++ 20
Our team is putting a lot of effort into the Clangd-based language engine. And the global C ++ community is actively developing Clang. In this release, we joined forces - we took the Clang experimental branch with support for concepts from C ++ 20, which is developed by Saar Raz, and poured it into our Clangd branch. Thus, we got code highlighting with concepts and basic checks of the Clang analyzer in CLion:
But we did not stop there. And in our Clangd-based engine, we implemented some useful cases of auto-completion, checking for the use of a concept,
Rename refactoring for concepts, navigation and search actions
Go to Definition and
Find Usages .
Auto-completion for template parameters that are subject to restrictions:
Auto-completion for
std::is_same<Other, T> and
same_as<T, U> :
You can read more about our joint work on concepts in the
English-language blog . There is also a video recording of the report from CppCon 2019, in which Saar Raz presented his concept implementation in Clang and our joint work on concept support in CLion.
Code Coverage Metrics
Code coverage is an opportunity that CLion users have been waiting for and asking for. In the last release, the AppCode team started work in this direction, and in this we picked it up for cases of cross-platform C ++ already in CLion.
CLion code coverage metrics work through integration with llvm-cov / gcov tools. In this case, you can run both unit tests and regular configurations, and according to their execution, the frequency of execution of certain lines of code will be calculated. The results of several launches can, if desired, be summarized in one general.
You can see the results directly either in a special Coverage window:
... or in the left gatter in the editor.
Well, and most importantly: for this to work, you need to pass special compilation options:
- For GCC:
-fprofile-arcs -ftest-coverage or --coverage . - For Clang: either the same flags as with GCC, or
-fprofile-instr-generate -fcoverage-mapping . Differences will only be in the method of assembling coverage metrics.
Why is CLion itself not passing these parameters? Mostly because we have a rule not to interfere with the compilation process. Yes, and itās not always clear where to pass these parameters in case of not CMake. But now we are thinking about options for how to automate such cases in the future (we have a similar problem with sanitizers).
You can read more about compilation options and about displaying metrics in CLion in our
online help .
Other improvements
Among other important improvements in this release:
- Support for the WSL2 subsystem. The settings in CLion are the same as those of the first version of WSL.
- Support for formatting and naming rules from Microsoft. This style is available on a par with Google, LLVM, Qt, GNU, Stroustrup and others in Settings / Preferences | Editor | Code Style | C / C ++.
- IntelliJ Rust Plugin Updates (a detailed post on our English-language blog is dedicated to these changes).
- VCS support updates, user interface and other changes from the IntelliJ platform.
Demo
In conclusion, a traditional video about the new features of CLion 2019.3 (in English):
Thank you for reading to the end! Surely you have questions, wishes, bug reports and just thoughts - we are waiting for them in the comments! As always, we will be happy to answer and discuss your ideas.
Your JetBrains CLion Team
The drive to develop