CLion 2021.3: New Remote Development, Better Data Views in Debugger, Docker Toolchain, Custom Compiler, Type Hints, and More
Read this post in other languages:
We are happy to announce that CLion 2021.3 is now available!
Check out the highlights and read the post for more details:
- New remote development mode (headless remote machine and thin local client)
- Toolchain updates
- Docker toolchain
- Custom compiler
- Environment script
- Windows-specific enhancements
- Ninja as the default CMake generator
- Type hints in the editor
- More powerful and accurate code analysis
- Plugin updates
Beta version of the new remote development functionality
Until now, remote development in CLion was focused on running the project build on a remote host, using remote host compilers and CMake/make, debugging with remote host debuggers, and running the application on the remote target. In this setup, CLion itself runs locally, and your source files are also stored on the local client, with automatic synchronization to the remote host.
However, there are several drawbacks to this approach:
- It’s not always possible (due to security reasons or otherwise) to store the source code on a local machine, in which case the code can only be located and used on a remote machine.
- CLion operations, such as indexing, can be quite heavy, so if the local machine is a thin client, there are significant performance issues.
We now have exciting news to share –
CLion now comes with long-awaited support for the new remote development workflow!
The main idea is to use a powerful remote machine to execute all IDE operations and to build, run, and debug code – all while running the IDE on a thin local client. A remote host is a physical or virtual machine hosting the source code and running the headless CLion to perform most of the IDE functions. Developers connect to the server with a thin local client (i.e. a physical machine, like a laptop) and use this thin client for development. We hope this setup helps you stay more productive and flexible while allowing you to work securely from anywhere.
You can find the documentation, Getting Started guide, and FAQ in our webhelp. In the following sections, we explain JetBrains Gateway as well as a few known limitations on the new remote development workflow in CLion.
JetBrains Gateway is our new application that serves as an entry point for all your remote backends. It runs on a Client and can be thought of as a lightweight launcher. It connects a remote server to your local machine, downloads necessary components on the backend, and opens your project in the JetBrains Client. It doesn’t require you to have an IDE installed on your local machine. You can grab the latest version of JetBrains Gateway from the Toolbox app or on the JetBrains website.
Use JetBrains Gateway as a stand-alone launcher or as an entry point from CLion to connect to a remote server. Check out this Getting Started guide.
It’s important to note that as of right now you are not able to initiate remote development sessions from CLion, but you can do so through JetBrains Gateway.
The remote hosts in this new remote development workflow are still Linux-only for now. Be sure that you have a compatible SSH server on the Linux platform. The Linux platform should have any recent Linux distribution such as Ubuntu 16.04+, RHEL/Centos 7+, and so on.
In the new remote development workflow in CLion, code editing, code analysis, navigation, running/building/debugging your code, and unit tests generally work. There are a few CLion-specific things to note here:
- CMake-only projects are supported; Makefile and Compilation database projects are coming soon.
- Process elevation and Run/Debug with root privileges don’t work (CWM-4091).
- CLion-specific debugger features (Memory View, Disasm) are not shown on a client machine (CWM-507).
- Code coverage is not shown on a client machine (CWM-921).
- The Sanitizers and Valgrind Memcheck are available, while the Profiler doesn’t start yet in the new remote mode (CWM-4284).
Please note that this is a beta version of the new remote development functionality and we’re still actively working to improve it. Please give it a try and let us know what you think. You can share your feedback or report any bugs here.
Better data views in debugger
When debugging, you really want to stay focused on important things. In this release, we customized the way the debugger renders data. The new settings are available in the context menu in the debugger tool window or in Settings/Preferences | Build, Execution, Deployment | Debugger | Data Views | C/C++ (or just Data Views, if all other language debuggers are disabled in CLion). You can now strip the information you are not interested in.
- In the variables view:
- Replace standard library types with more readable aliases.
- Remove global and function scope specifiers and the
- Hide variable types completely.
- In the frames view, in addition to the settings mentioned above:
- Hide function parameters and template arguments.
- Display module names, which help you guess which binary the code is being run in at any moment and display the thread ID given by the OS on thread start.
- In the same settings, you can also enable/disable the updated Hex view for numeric variables.
To get a more readable representation of continuous memory storage of the objects of one type, a new View as Array… action is available for any pointer variable. This action adds a watchpoint that renders a pointer value as an array. Just call the corresponding action on a pointer variable and specify the size of the array:
Among other debugger improvements are the Parallel Stacks View and bundled LLDB v13.
Debugger updates for embedded development
The RTOS thread view in the debugger was expanded to Zephyr OS. You can enable the integration in Settings/Preferences | Build, Execution, Deployment | Embedded Development | RTOS Integration. The FreeRTOS thread view which was added to CLion earlier was expanded by adding object and heap views. Learn more from CLion’s webhelp.
Docker and other toolchain updates
In CLion, a toolchain is a set of all the necessary tools required to build and run your application. Given the variety of possible tools in the C++ ecosystem, it’s important to have a way to configure them in the most concise way. CLion v2021.3 makes toolchains more flexible and easier to configure and customize.
We’ve introduced the Docker toolchain and recommend that you use it instead of configuring the Remote toolchain for your Docker container. It avoids redundant source code synchronization, as the project folder is simply mounted to the container. Create the toolchain in Settings/Preferences | Build, Execution, Deployment | Toolchains, select the Docker image you need, wait until the tool detection finishes, and save the settings. Now you are ready to use your Docker toolchain for project development. Watch the video to learn more:
The following changes are especially useful for embedded development, which allows you to configure toolchains with a huge variety of compilers and specific settings:
- The Custom Compiler option makes it possible to use compilers that are not supported by CLion natively in CLion. Right out of the box, CLion can detect and work with GCC, Clang, Clang-cl, MSVC, and IAR compilers. For other compilers, you can now provide the *.yaml file that contains your custom compiler definition. Learn more from our webhelp and check out the sample configs on GitHub for several of the most popular cases prepared by the CLion team.
- You can now initialize the environment in which the compiler runs via script in CLion. Such scripts normally set compiler environment variables, customize the PATH variable, and more. A new option for the script was added to the toolchain configuration.
A few Windows-specific enhancements were introduced in CLion v2021.3:
- The System toolchain can be useful for ARM or other embedded configurations on Windows. It allows you to configure the
makeexecutable, compilers, and the debugger without selecting a predefined toolset and environment, similar to Linux and macOS.
- For those starting with CLion on a Windows machine without any compilers configured, MinGW is now bundled in CLion. The exact version bundled is MinGW-w64 9.0 with
languages=c,c++, posix threads, and
Watch the video to learn more:
The CMake project model has received some updates, too:
- We’ve updated it to v3.21.1, meaning that CMake Presets v3 are now also supported in CLion.
- For version 3.20 and higher, CLion now uses CMake File API as its default approach when querying project information. If you prefer the legacy approach, which involves CLion parsing the output of the CMake command that is run with the Makefiles generator, you can still enable this in the settings.
- Ninja has become a default generator for newly created and newly opened projects in CLion for local toolchains (i.e. excluding Remote, Docker, WSL) and CMake v3.20 and higher. Along with this change, Ninja v1.10.2 was bundled in CLion. Ninja seems to be one of the most effective generators for CMake currently, so we encourage you to use it in your projects. There are still some issues like non-colorized output (CPP-17786), which we plan to address in upcoming versions.
- A new UI for setting the CMake generator was added to the CMake Profile settings page Settings/Preferences | Build, Execution, Deployment | CMake. Users can use the default value for the selected toolchain or set any generator from the predefined list:
Type hints in the editor
In some cases it might not be obvious which type is used in a specific location in the code, such as for
auto variables, in structured bindings, and for lambda return types. To increase code readability, CLion 2021.3 adds type hints for deduced types.
Given that modern C++ code can avoid mentioning types at all, this can be a real help:
Combined with the parameter hints added in the previous versions, these hints make reading and maintaining code in C++ much easier:
More powerful and accurate code analysis
CLion 2021.3 includes a list of fixes for Data Flow Analysis. The analysis is now call-context-sensitive. This means it treats different function calls differently without mixing the data taken from them for analysis. CLion’s lifetime analysis, which is implemented via DFA and based on Herb Sutter’s Lifetime Safety proposal, has been enhanced and can now identify dangling iterators and modified owners.
This update also brings new MISRA checks (the up-to-date list of supported checks) and updates LLVM tools including Clang-Tidy to v14.0.0.
Space IDE plugin updates
Did you know that you can connect CLion to Space to get access to your repositories, code reviews, Automation (CI builds), and packages? You can install the Space plugin manually in CLion.
Merge requests and code reviews are central to the workflow of many development teams. Wouldn’t it be great to be able to work on code and ask for reviews in the same place? The updated Space plugin now lets you do all of this from within CLion!
- Create merge requests and assign teammates for code reviews from the IDE.
- Mark files as viewed/not viewed to keep track of where you are in a code review.
- Add reactions in code review chats to communicate with your team more easily.
Read the documentation to learn more.
Rust plugin updates
IntelliJ Rust provides improved support for declarative macros 2.0. Procedural macro support, an experimental feature at the moment, has received updates as well.
The plugin now fetches full stdlib info, including the dependencies and Cargo features.
The new name resolution engine now supplies data for the Auto-import quick-fix and for completion of items outside the current scope. This makes auto-import available for macros and improves processing of complex re-exports – all while boosting performance.
ML-assisted completion was enabled by default. Crate and version completion in Cargo.toml has been improved significantly thanks to local indexing of the crates.io metadata. The plugin also added a quick-fix to qualify full paths and new refactoring to extract struct fields.
On the running and debugging side, code coverage now works for stable toolchains, WSL support is enabled by default, and the debugger is capable of automatically breaking on “panic!”.
You can find more details in the dedicated blog post.
A quick glance at just a few of the changes:
- A new Build directory option was added to Settings/Preferences | Build, Execution, Deployment | Makefile for configuring the directory where all
maketasks are executed when the Makefile project is loaded in CLion.
- Gradle and Gradle Native plugins in CLion are now unbundled and can be installed from our marketplace.
- A new toggle was added to the Structure tool window and the Structure pop-up to show qualified names for the member functions and to help you more easily distinguish functions with the same names.
- The new Push All up to Here action allows you to push commits up to the one you have selected in the Log tab of the Git tool window.
- To improve CLion performance for projects on WSL, the Clangd-based language engine is now run directly on WSL in such cases.
We encourage you to give CLion 2021.3 a try. If you have an active subscription, you can update today. Otherwise, start your free 30-day trial to check out the new features and see what you think!
Your CLion team
The Drive to Develop