CLion 2019.3: A Quality-Targeted Release Focused on Performance and Some Long-Awaited Enhancements
Exciting news! CLion 2019.3, the last major update this year, has just been released!
Improving the IDE performance and fixing major bugs are always a top priority for our team. In this update we have been focusing especially on improving the performance in specific areas, eliminating UI freezes (not all, but many of them have been melted away!), and enhancing the editor and the integrations for our users!
To update to this version you can use the Toolbox App, snap package (on Ubuntu), our website, or the patch-update from the latest build of 2019.2.
If you are just looking for a quick overview of the main highlights, take a look at the list below. If you are interested in the specific details, please read on:
- IDE Performance
- Debugger updates
- More opportunities in CMake
- Switching between Header/Source files
- Code Coverage
- C++20’s Concepts
You can also get a good overview of this release by checking out this short What’s New video by Phil Nash:
IDE Performance
During this release cycle, there were many activities focused on improving the IDE performance, both in the IntelliJ Platform and in CLion in particular.
From the IntelliJ Platform side, a number of significant architectural changes were introduced in order to reduce the IDE startup time. These changes include but are not limited to:
- Parallelization for some of the processes that used to run one after the other.
- Reorganization of the classes in a way that makes the initial class loading faster.
- Optimization of the font loading on macOS.
From the CLion side, we’ve made a massive effort to eliminate UI freezes. While there are still some freezes left (it’s mainly with some of the more complex C++ projects), a lot of others have been melted away. We’re planning to keep up the intensity of this work over the next releases, of this you can be sure! Besides this, we’ve optimized the Building/Updating symbols step by reworking some of the underlying algorithms. Depending on the specific project, CPU, and environment, you can expect a boost of somewhere between 10% and 50%, according to our calculations.
The team has also worked on improving the performance by reworking some of the current core functionality provided by the IDE. First, the Rename refactoring now has a mode where it first asks if you’d like to rename non-code usages (like occurrences in comments and strings literals) and only then performs a search for all the occurences. This, however, requires the in-place mode for Rename to be turned off (Settings/Preferences | Editor | General | Refactorings | Enable in-place mode).
What is probably the most widely used feature of any IDE or smart text editor? That’s right, code completion! To speed up the code completion in CLion, we’ve implemented an additional completion provider. It’s based on Clangd and produces results faster than the other providers in many of the h eavy cases like LLVM, Boost, Qt, or Eigen:
Learn more details on the measurements.
Debugger updates
CLion integrates with GDB and LLDB debuggers, and in this release we have worked on this integration to make it more user-friendly and higher-quality.
For LLDB, we’ve updated the bundled version to v9.0 and performed a major cleanup in the bundled pretty printers. As a result, the standard containers are now visualized more accurately. You can expect much better support for libc++ on macOS than for libstdcxx (let us know if you are using the latter on macOS, and specify the toolchain you use, so that we can consider making improvements). On Ubuntu, the only difference is in the unordered associative containers. Check out a detailed comparison here.
For both GDB and LLDB, CLion now supports reading .gdbinit/.lldbinit from the project root (previously CLion could only read these files from the User’s home directory). This allows you to tune the debugger’s behavior without affecting all the projects on your machine. Note that to enable this behavior, you have to explicitly allow .gdbinit/.lldbinit in your home directory:
- For GDB:
- Globally:
set auto-load local-gdbinit on
add-auto-load-safe-path / - Per project:
set auto-load local-gdbinit on
add-auto-load-safe-path C:\work\myproject\.gdbinit
- Globally:
- For LLDB:
settings set target.load-cwd-lldbinit true
A typical use case is to provide custom pretty printers for some data types in your project:
And finally, a new Remote GDB Server configuration was added which has made it possible to enable remote debugging over ssh. The main benefit over the previously added GDB Remote Debug configuration, is that CLion uploads the executable to the remote host and launches your program under the gdbserver there automatically. Read the details in our webhelp. This means there are now 3 options to connect remotely from a locally running CLion – Full Remote mode (when you build, run and execute remotely) and 2 options for a remote debug (when only the debugging is done on a remote host).
More opportunities in CMake
CMake is known to be the first-class citizen project model in CLion. Many CLion users rely on it and some users have even converted their projects to CMake to be able to work in CLion. We very much appreciate this strong support, and in this release we have addressed two of the biggest shortcomings with the CMake integration in CLion.
One way we have addressed this is, of course, with the Ninja generator! Moreover, it’s now possible to use any available generator in CMake. Just pass it to the CMake options in the CMake Profiles settings:
The implementation is based on the CMake File API and, as such, is available when CMake 3.15 or higher is used.
We’d like to thank the many EAP users who gave it a try so soon after the feature was released. The feedback we got has helped us address a lot of the issues before the official release.
Another issue we wanted to address was the missing ability to configure some CMake settings globally for newly created projects in CLion. For example, a template for the generation path or some environment settings. Now you can do it with CMake Defaults! Use File | Other Settings | Preferences/Settings for New Projects…
And finally, we addressed another unpleasant issue in this release – if some CMake configurations are invalid and fail to reload, CLion won’t fail now but instead it will successfully reload all possible valid configurations. The typical use case for this is when you don’t have your remote configuration currently connected and there are several local configurations which you’d like to reload. Previously, the whole reload process would simply fail, but now the local configurations will be reloaded successfully.
Switching between Header/Source files
To switch between header and source files, CLion now offers a more effective and more accurate heuristics-based action called Go to Header/Source. Use it instead of the more general IntelliJ-platform Go to Related Symbol action.
The new action tries to locate the single destination file, and if it fails in 500 ms, then it shows an interactive popup where the new items are added (and more importantly are calculated in the background, so no UI freezes!). Then, you can select where you want to navigate to.
The Go to Header/Source search relies on several heuristics, for instance, the most recently switched file is always at the top of the list, and the file with a matching name from the same directory has priority next.
There is only one limitation you have to keep in mind for now – the search is currently limited to direct includers/includees, as this helps to avoid interference from the same symbols from different targets.
Code coverage
While this release was mostly focused on bugs, technical debt, and performance challenges, a few features have still made it through. Code coverage – one of the most top-voted requests in our issue tracker – was addressed by adding integration with llvm-cov/gcov tools.
You can run unit tests and regular configurations with Coverage, just don’t forget to pass the special coverage compilation options. This has to be done manually, as CLion won’t willingly modify your CMake files and compilation options.
The results of the measurements can be checked in a separate Coverage tool window, or it can be done right in the editor – the coverage is indicated with color in the left-hand gutter.
Read more details in our webhelp.
C++20’s Concepts
During the last couple of release cycles, we were experimenting with our Clangd-based language engine. The idea was to merge another experimental branch – Saar Raz’s clang branch with Concepts support – and build a few unique features on top of it. The idea was first discussed when we met Saar at the Core C++ conference in Tel Aviv, in May 2019, and now with CLion 2019.3, we are ready to deliver the results of this collaboration.
In CLion, the Clangd-based engine now assists with parsing and highlighting C++20’s Concepts properly. There are also a few code checks from Clang, and an Unused concept inspection implemented by the CLion team.
Still, the most impressive work was done in code completion, as CLion can now complete template type parameters that are constrained, as well as types constrained by std::is_base_of<MyBase, T>, std::is_same<Other, T> and same_as<T, U>:
Besides this, there is support for Rename refactoring, Go to Definition, and Find Usages navigation actions. You can find more samples and learn about how to enable C++20’s Concepts support in the compiler in our dedicated blog post.
We’d like to thank Saar Raz for his fantastic work in Clang and his productive collaboration with our team!
Other fixes and improvements
The Spell Checker is an essential part of the IDE, which helps keep your comments, string literals and in-code documentation correct and readable. In CLion 2019.3, it is able to spell check CMake files and Doxygen comments:
In addition to WSL, CLion now also supports WSL2. The configuration process in the IDE has stayed the same, just keep in mind that there are some differences in the user experience between these two subsystems.
A new inspection virtual functions called from constructors or destructors was added to catch situations where virtual functions might have access to resources that are not yet initialized or that have already been destroyed:
Microsoft formatting and naming rules were added as a predefined code style option, enhancing the list with Google, LLVM, Qt, GNU, Stroustrup, and other styles.
Since CLion is based on the IntelliJ Platform, there are also VCS improvements and dozens of UI issues resolved. For those of you who use CLion as a Rust IDE, we are happy to share with you that the IntelliJ Rust plugin has had a massive update (we plan to dedicate a separate blog post to it, so stay tuned!).
And that’s it! Hopefully you are not tired from all the reading and are excited to give the new release a try now! We’d love to hear any feedback you have for us on this release!
Your CLion Team
JetBrains
The Drive to Develop
Subscribe to CLion Blog updates
