CLion 2020.1: Dozens of Improvements Across the IDE, and Benefits for CUDA and Embedded Projects
Let’s start with a big wish for everyone to stay safe! While it’s obviously sometimes hard to focus on your work these days, as there are other important things happening, we’ve tried our best to keep doing what we are good at – creating great tools for developers to increase their productivity. So we are here to introduce a fresh CLion 2020.1 release!
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.3 (2019.3.5).
Here is a quick overview of the main highlights. If you are interested in the specific details, please read on:
- CUDA projects
- Embedded development
- Windows projects
- Clang-based tools update
- Refactorings, formatter, documentation, and editor enhancements
- Run/Debug configurations
- IntelliJ Platform updates
- What’s going on with Makefile support?
CUDA C and C++ are essentially C/C++ with a few extensions, and CLion 2020.1 is now able to handle CUDA code correctly. Most of our effort was put into teaching CLion’s language engine to parse such code correctly, eliminating red code and false positives in code analysis. The enhanced support also includes code navigation, code documentation, and other code assistance actions that work within CUDA code. And finally, code completion was expanded to complete angle brackets for kernel calls:
(For the test, we used the ClaraGenomicsAnalysis project from GitHub.)
Additionally, CLion now supports CUDA file extensions – .cu/.cuh. You can select them when creating new C/C++ files. By the way, did you know that CLion suggests CMake targets to add your newly created files to? Now CUDA targets (created with
cuda_add_library) are added to the list of possible options to select from:
Finally, you can start a new CUDA project in CLion – the New Project wizard helps you generate the sample CMake and main.cu files. Learn more about how to work with CUDA projects in CLion in our webhelp.
We keep improving CLion for embedded development, and in this release we’ve taken two important steps forward. The first is IAR compiler support. CLion can now collect compiler information correctly, making it possible for you to successfully use the compiler in your embedded projects. Here are a couple of useful tips to get you started with the IAR compiler:
- MinGW is required. Use the MinGW environment in the IAR toolchain settings in CLion and provide paths to the IAR compiler in the corresponding fields.
- Check out these notes on how to use CMake with IAR Embedded Workbench.
We’d like here to once again thank IAR Systems AB for their support and partner licenses. And we’d also like to assure our readers that we’ll continue the collaboration. Our next goal is to further investigate integration with this toolchain.
Our second big step forward is the ’PlatformIO for CLion’ plugin. PlatformIO is a new generation ecosystem, and it can be super useful for getting started quickly with an embedded development project (for example, for Arduino). The plugin generates a PlatformIO CMake-based project when the corresponding project type is selected in the New Project wizard, calling a proper PlatformIO command for you in the background:
For such projects, CLion automatically creates configurations for debug and upload. You can also create a PlatformIO Debug configuration to use the PIO Unified Debugger. Read on for more details in the official documentation.
We’ve seen a growing number of developers on Windows using CLion. Actually, Windows is a primary platform for our users, according to our statistics. That is why we have focused on a few of the most popular requests from the Windows community.
Clang is the second most popular compiler after GCC (according to The State of Developer Ecosystem 2019 study). Microsoft Visual Studio Compiler is of course the leader on Windows, but Clang-cl is also widely used. You can install it from the LLVM website or along with the Visual Studio tools. And it’s now possible to use it within CLion!
Another good piece of news for Windows developers is that the LLDB-based debugger developed by JetBrains for the Visual Studio C++ toolchain is now the default debugger for this toolchain. So you can start using it right away! In the screenshot above, you can see it’s preselected for the Visual Studio toolchain. Please note that this debugger is not a regular LLDB build. Rather, it is developed by the JetBrains team and can handle Native Visualizers (to enable Native Visualizer support, go to Settings | Build, Execution, Deployment | Debugger Data Views | Enable NatVis renderers for LLDB).
Check out this short demo:
Clang-based tools update
In another important development, our team is moving to our Clangd-based language engine wherever possible. There are two main reasons behind this move. First, we want to develop more accurate language features to catch up quickly with the recent updates to the language standard. Second, we want to improve the performance of language agnostic actions (which is not always possible with Clang, but we continue to experiment with more features).
In CLion 2020.1 we’ve moved Dataflow Analysis fully to Clangd. What is DFA, and why is it useful? DFA checks analyze how data flows through your code and detect potential issues based on that analysis. For example, they identify conditions that are always false or always true, endless loops, missing return statements, infinite recursion, and more:
Most compilers don’t do that for you. For sure, DFA requires very accurate code parsing and resolve, and it can take a significant amount of time, especially when the underlying resolve is slow. So moving to Clangd is a step toward improving the performance of such analysis checks.
In previous versions of CLion, we introduced a Clangd-based completion provider. But at that time it worked in combination with CLion’s own providers. During the 2020.1 iteration, we polished the completion provided by Clang (by fixing dozens of related issues and adding missing completion features) and finally enabled the mode in which Clang is the only provider for code completion in CLion as the default. This resolves some prioritization and ordering issues.
ClangFormat and Clang-Tidy are standard tools for many C++ projects, and their config files are often committed to project repositories. CLion’s integration for these tools, however, was not switching to them automatically. We sincerely thank our users who pointed out this inconvenience! CLion now:
- Detects the .clang-format config file in the project root and switches to ClangFormat for you automatically (note that the IDE switches to per project settings at this moment).
- Detects the .clang-tidy config file and automatically turns off the use of the IDE settings for Clang-Tidy in favor of this config file.
We do hope this makes working with these two Clang tools much nicer for you!
Check out this short demo:
Refactorings, formatter, documentation, and editor enhancements
With CLion you receive many useful refactorings, and one of the most popular is Change Signature (Ctrl+F6 on Windows and Linux, ⌘F6 on macOS). It allows you to change the function name and return type, as well as add, remove, and reorder parameters. And the biggest value (in comparison to manually updating the function) is that when changing a function signature, CLion searches for all usages of the function and updates all the calls, implementations, and override replacements of it that can be safely modified to reflect the change.
Here you might ask: What happens to a function usage when a new parameter is added? Previously, CLion added the default type value to the usages as an argument (i.e.
0 for numerical,
nullptr for pointers) in order to keep your code compilable. With CLion 2020.1, you can tell CLion right in the refactoring dialog which value to substitute across all updated function usages:
Note the code completion available in the new Default value field in the dialog! If you keep the field blank, the old behavior is applied and the default value for the type is used.
The formatter has been updated in this release, with new separate naming settings for struct member fields and class member fields. And code foldings now work for
#pragma region and
Other editor updates include:
- Quick Documentation – a universal tool to preview documentation and get information about function signature, inferred types, and macro replacement – is now available on mouseover.
- The default font in the editor has been changed to JetBrains Mono, a new open source font created by JetBrains.
- A new default light theme – IntelliJ Light – is now the standard theme across all the different operating systems.
- And if you need several terminal sessions to work with at once, you can now split your terminal vertically or horizontally so that you can run multiple sessions side by side:
Check out this short demo:
Run/Debug configurations help you launch applications for running and debugging them from within CLion. In this release, they’ve received several important updates:
- The Remote GDB Server and Embedded GDB Server configurations now work with custom targets. This allows you to debug your application on a remote host or on the microcontroller from the CLion instance running on your local machine, not only in CMake-based projects but in any custom applications (including compilation database).
- Google Test targets for v1.8.1 and higher are now recognized correctly in CLion, and corresponding Run/Debug configurations are created automatically (making it possible to run tests in CLion’s built-in test runner).
CLion 2020.1 brings macros and path variables to Run/Debug configurations:
- Macros are predefined, and you can look through the list of available macros in the dialog that opens when you click on a plus sign in the Run/Debug configurations dialog. Note that macros are only available for CMake, Custom Build, and Gradle Native Applications at the moment.
- Path Variables can be configured in Settings/Preferences | Appearance & Behavior | Path Variables. The typical use case is to create a Path Variable for a library that is used widely in your projects but that is located outside the project directory.
The Prompt/FilePrompt macro is especially useful when combined with the new Redirect input from field in the configuration. This field helps you redirect input from a file to the stdin of your application, and the FilePrompt macro invokes a file selection dialog every time the application launches:
Check out this short demo:
IntelliJ Platform updates
As usual, VCS and other IntelliJ Platform improvements are coming to CLion, in addition to an update for the IntelliJ Rust plugin. More info on the latter will be published separately very soon, so stay tuned!
What’s going on with Makefile support?
Whoa whoa whoa! Who said anything about working on Makefile support in CLion?! Well, whoever they were, they were correct. We’ve built a prototype of the Makefile project analyzer inside CLion and did a blog post on the approach we took and the state of the current solution. And with the help of our faithful users, we’ve built a list of projects for testing this prototype.
There are approximately 40 projects on the list at the moment, and more than half of them have been checked (CPython, some embedded projects, Nano, Nodejs, PostgreSQL). For the most part, they worked fine. Still, there are some projects on which the prototype failed (for example, because of wrappers like libtool). You can find GCC, FreeBSD, Wine, and Perl among these unsuccessful projects. There are also some brave users who tested the prototype on their private projects and gave us some really valuable feedback! Thank you all for that.
So the work continues. We plan to make the prototype public in the 2020.2 EAP. In the meantime, if you are willing to help with this endeavor, check out this call.
That’s finally it! Please give CLion 2020.1 a try. Update today if you have an active subscription, or start your free 30-day trial to evaluate the new features!
Your CLion team
The Drive to Develop