A new CLion 2021.1 EAP build (211.6305.15) is now available from our website, via the Toolbox App, or as a snap package (if you are using Ubuntu). Note that if you are on macOS, there is a separate build for Apple Silicon (M1 chip).
If you ever ask yourself how well your code is covered with tests, code coverage tools may help answer the question. Code coverage integration in CLion is available on all three platforms (Linux, macOS, and Windows) and with any toolchain (local, remote, or WSL), but only for CMake projects.
When you measure your code coverage, there are several criteria and approaches to how to do it. Previously, CLion was only able to measure Line Coverage (for GCC and gcov) and Statement Coverage (LLVM and llvm-cov). It showed how many lines/statements in your code (in %) were executed while running the tests.
But now, starting with this 2021.1 build, CLion can also show Branch Coverage. It takes into account all the branches of each control structure. For example, given an if statement, it can tell you if both the true and false branches have been executed.
In the CLion UI, this is displayed in the Code Coverage tool window, in the column next to the Line Coverage:
Image may be NSFW. Clik here to view.
Please note that branch coverage is supported for LLVM version 12.0.0 and higher and for any version of GCC. It’s enabled by default in Settings/Preferences | Build, Execution, Deployment | Coverage. However it does nothing if your LLVM is older than 12.0.0:
Image may be NSFW. Clik here to view.
It is also important to note that GCC and the gcov tool consider the compiler-generated branches when calculating branch coverage. This might affect the results if, for example, you use exception handling.
We’d like to thank zero9178, the author of the 3rd-party plugin C/C++ Coverage for CLion, who inspired us to add Branch Coverage to CLion.
Move execution point in disassembly view
The Set Execution Point action lets you jump to an arbitrary line of code in the editor during a debug session and set the execution point there, skipping all the other commands in between. It now works in the disassembly view, so you can move the execution point while stepping through the assembly code.
New MISRA C and C++ checks
We’re continuing to add MISRA C and C++ checks to CLion. A table with all supported checks can be found here. This time we added such fixes as:
The unary & operator shall not be overloaded
A pointer to a virtual base class shall only be cast to a pointer to a derived class by means of dynamic_cast
The statement forming the body of a switch, while, do … while or for statement shall be a compound statement
and a few others.
If you endeavor to comply with MISRA C or MISRA C++ guidelines in your project, please let us know if you find the CLion checks helpful. Thank you!
Initial support for Remote Makefile projects
CLion now comes with support for Makefile projects with remote toolchains. They previously didn’t work together, as the full remote mode was only supported for CMake projects. But starting with this 2021.1 EAP build, CLion can handle remote Makefile projects! There are still a few limitations for it, so read on before giving it a try.
Like before, you can work on a macOS, Linux, or Windows desktop targeting a remote Linux machine connected via SSH, and the project source code should be located on the local machine. The CLion instance runs locally and synchronizes the source code to the remote machine, where it performs compilation using host compilers. You can run and debug your application or unit tests on a remote machine from the locally running CLion.
To make it work for your Makefile project:
Change the toolchain used by your Makefile project in Settings/Preferences | Build, Execution, Deployment | Makefile to a remote one configured in Settings/Preferences | Build, Execution, Deployment | Toolchains.
Call Tools | Makefile | Clean and Reload Makefile Project.
CLion will synchronize the project with the remote machine and will reload it for you:
Image may be NSFW. Clik here to view.
In the example above, we loaded an Mbed TLS project on our remote Linux machine from a Mac.
Known issues and limitations:
Remote Makefile projects are only supported when Makefile is present in the project directory. If, for example, a pre-configure step is required, CLion can’t automate it for now (CPP-16924).
The toolchain update in the settings doesn’t trigger an automatic project reload. This is something we plan to address in the future (CPP-18982).
We recommend using Tools | Makefile | Clean and Reload Makefile Project and not Tools | Makefile | Reload Makefile Project as there are some occasional issues with the command cache.
When uploading a Makefile project to a remote machine, CLion uses a directory containing the Makefile as a project root (CPP-23995). If you have Makefile located in a different subdirectory, you need to update the path mappings in the Deployment settings (Settings/Preferences | Build, Execution, Deployment | Deployment) – changing the local path to the correct project root.
A new Open Remote Host Terminal action
Sometimes when working with a remote project in CLion, you might want to open ssh to the remote host and execute some command in the project directory. Tools | Start SSH Session… can help you with that, but it won’t open the current project directory on a remote host by default. So we’ve added a new Tools | Open Remote Host Terminal action to do exactly that – it opens the project directory on the remote host if it exists. The remote host corresponds to the currently selected remote profile, or, if a local one is selected, the first remote profile found in the project:
Image may be NSFW. Clik here to view.
The action works for both remote CMake and remote Makefile projects supported currently in CLion.
We’ve also improved performance for the CMake load step when a remote toolchain is used (CPP-17421). The full release notes are available here.
The new CLion 2021.1 EAP build (211.6432.9) is now available. You can get it from our website, via the Toolbox App, or as a snap package (if you are using Ubuntu). Note that if you are on macOS, there is a separate build for Apple Silicon (M1 chip).
We continue our work on extending the list of supported checks. You can find the current list of supported checks on our confluence page here. We keep this page updated so that you can easily get a sense of the current state of the support, i.e. how many checks are covered by CLion. We’ve added a few new rules this week:
The condition of an if-statement and the condition of an iteration-statement shall have type bool. The first operand of a conditional-operator shall also have type bool.
Named bit-fields with signed integer type shall have a length of more than one bit.
A few rules for throwing, like NULL shall not be thrown explicitly, and an empty throw (throw;) shall only be used in the compound-statement of a catch handler.
We’d like to remind you that MISRA inspection settings can be found in CLion in Settings/Preferences | Editor | Inspections | C/C++ | General | MISRA Checks. You can configure the list of C and C++ checks to run on your project.
Debugger enhancements
In the previous release, CLion v2020.3, we added an ability to debug with core dumps. This helps you investigate the reason for a process crash by debugging the generated core dump right in CLion. In this EAP build we are happy to announce a few improvements to it:
If the crash happened in binary that does not have debug symbols, you still can debug it in CLion by providing symbols to the debugger explicitly (for example, via a non-stripped binary as a symbol file). This already worked for GDB when 2020.3 was released, and with this EAP it now also works for LLDB.
The Core Dump Debug run configuration now allows you to set the sysroot. This option is essential for debugging core dumps from binaries built on other systems where the libraries are located in some non-default location. Specifying this path in the new field will allow CLion to locate the library symbols correctly: Image may be NSFW. Clik here to view.
How do embedded developers set up everything they need to do programming? A typical wired setup includes a device that stays on the developer’s table, and a ribbon cable that connects it to a debug probe, which in turn is connected to the developer’s computer by a USB cable. The computer is running probe-specific software and an IDE.
In many cases, this setup works fine. But embedded devices work with real-world objects. Sometimes an MCU-based control board manages high-voltage or dangerous equipment. Sometimes it’s mounted outdoors. The equipment could be moving on wheels, or floating on the water. It could even be mounted in a remote location. Using a cable setup in these cases is generally inconvenient and could even be dangerous.
When I started developing an outdoor device, I immediately encountered this problem. What could be done? I took stock of what I had available to me and found a Raspberry Pi board. I have spent several hours setting it up as a wireless debug probe, and now it works like a charm.
Every ARM-based MCU has a two-wire debug interface (SWD) and a reset line. These three lines are supposed to be connected to a debug probe. In my wireless setup, I use my Raspberry Pi GPIO pin header to connect directly to the device. On the software side, my Raspberry Pi is running the open-source on-chip flashing and debug utility OpenOCD as a remote GDB server, and I connect a debugger, bundled with the CLion IDE, to it over Wi-Fi. Open network communications might be unsafe, so I wrap a TCP channel between GDB and OpenOCD into an SSH tunnel. Here’s a schematic representation that captures the differences between these two setups.
Regular setup:
Image may be NSFW. Clik here to view.
Wireless setup:
Image may be NSFW. Clik here to view.
Which board is better suited?
In my setup, I used Raspberry Pi Zero W, and I think it’s a very good option. It’s small. It already has Wi-Fi on board. It consumes relatively little energy. It does not need a fan for cooling. It’s sold everywhere. And it’s fast enough to do the job. But, this board has a couple of disadvantages relative to RPi 2+. It has a slower CPU, and setting it up from scratch might take longer. Further, RPi Zero W only supports 2.4GHz Wi-Fi networks, not 5GHz.
You can use whichever Raspberry board you prefer. The only major differences are the network setup and the OpenOCD configuration parameters that need to be adjusted: bcm2835gpio_peripheral_base and bcm2835gpio_speed_coeffs.
Raspberry PI OS and connectivity
First of all, we need to get our Raspberry Pi up and running, and connected to the Wi-Fi network. This requires an empty SD card, and 4 GB should be sufficient.
The very first step is to copy an OS image to the SD card. The best choice is Raspberry Pi OS (32-bit) Lite. You can find the official installation instructions for Windows, Linux, and MacOS here.
Once the image has been written to the SD card, the next step is to ensure that the board will connect to a Wi-Fi network. Eject and insert your SD card back into the reader, and then follow these instructions for setting up Wi-Fi headlessly. (Note that RPi Zero W only supports 2.4GHz Wi-Fi.)
Now write a file named ssh to the SD card’s root folder. The content of the file is not important, and even an empty file will do. This will activate the ssh server for remote access when Raspberry is booted. More details.
Now we can insert the card into Raspberry Pi and turn it on. If everything is done correctly, in a couple of minutes the board will appear as a new Wi-Fi device in the network. Its IP address can be found on the Wi-Fi router DHCP status page. I’d recommend setting up a permanent IP address for the board there. In my case, it is 192.168.0.110.
To take control of the board, we need an ssh client. Use the ssh utility on Linux and MacOS or putty on Windows:
ssh pi@192.168.0.110
putty.exe pi@192.168.0.110
The default password is raspberry. We highly recommended changing the password as soon as you log into the board. Use the passwd command to do so.
The next step is to update Raspberry OS. This is time-consuming, but I’d recommend doing it anyway. It’s best to keep all the Linux software up to date. The commands:
will do the trick. Reboot the board (sudo reboot), and log back in using your new password.
OpenOCD installation
Since there isn’t a pre-built binary package of OpenOCD for Raspberry, we need to build it ourselves. This process could take some time, so please be patient.
First of all, Git, build tools, and libraries must be installed with the following command:
Now we need to download the OpenOCD sources. For our purposes, we only need the latest revision, and a shallow clone of the Git repository should be sufficient. The following command will make that clone in the openocd-git folder:
Let’s configure, build, and then install the actual utility. The commands in the following sequence should be called one by one:
cd openocd-git
./bootstrap
./configure --enable-linuxgpiod --enable-bcm2835gpio --enable-sysfsgpio
make
sudo make install
Once these commands have finished running, OpenOCD is ready.
Final Raspberry settings
OpenOCD is a utility for in-system programming and on-chip debugging. It supports a number of various microcontroller cores and different flashing interfaces and different protocols. OpenOCD uses three types of configuration files:
Probe interface configurations.
Target device core configurations.
Board configurations, which usually include a reference to the probe interface, a reference to the core configuration, and optional tweaks.
We are not going to touch the cores, but we do need a probe interface configuration. The following command creates such a config, named rpi1-gpio.cfg, at the pi user home.
cat <<EOF > ~/rpi1-gpio.cfg
#
# Config for using Raspberry Pi's expansion header
#
# This is best used with a fast enough buffer but also
# is suitable for direct connection if the target voltage
# matches RPi's 3.3V and the cable is short enough.
#
# Do not forget the GND connection, pin 6 of the expansion header.
#
adapter driver bcm2835gpio
bcm2835gpio_peripheral_base 0x20000000
# Transition delay calculation: SPEED_COEFF/khz - SPEED_OFFSET
# These depend on system clock, calibrated for stock 700MHz
# bcm2835gpio_speed SPEED_COEFF SPEED_OFFSET
bcm2835gpio_speed_coeffs 113714 28
# Each of the SWD lines need a gpio number set: swclk swdio
# Header pin numbers: 22 18
bcm2835gpio_swd_nums 25 24
# If you define trst or srst, use appropriate reset_config
# Header pin number: 26
# bcm2835gpio_trst_num 7
# reset_config trst_only
# Header pin number: 12
bcm2835gpio_srst_num 18
reset_config srst_only srst_push_pull
# If you have both connected,
# reset_config trst_and_srst srst_push_pull
transport select swd
EOF
From the configuration file above we can see the GPIO header pinout:
And there’s one final, optional step. It can be easy to forget the pinout of the wireless probe, but we can make an easy reminder. The following command adds a login banner with the pinout.
The next time we forget the pinout, we can just log back in the Raspberry and it will be displayed on the banner.
Image may be NSFW. Clik here to view.
Now we’ve finished setting up the Raspberry software. We’ll next move on to look at the hardware and the firmware example project. But before we do, there’s one last point we need to consider.
Setting up the example project
The CLion IDE and an ARM embedded toolchain are required to try the example. Instructions for setting them up can be found here and here, respectively.
For the example project, I’m going to use the MCU soldered onto a STM32F3-Discovery board, but with RPi instead of the on-board ST-LINK interface. The example project can be cloned from a GitHub repository. The project is written in C and C++17.
Hardware wiring
First, I detach both jumpers from the “ST-LINK” connector. The on-board flashing probe is now disconnected from the MCU.
The target MCU for this demo is powered by the Raspberry Pi itself, using pin 2 of the GPIO header.
Note! If you make your own device, make sure your target device supports 5 V power supply voltage, and does not consume more than 200 mA. Otherwise, use some other power supply scheme.
So, the wiring should look like this:
Rpi Pin 6 -> GND -> DISCO GND
Rpi Pin 12 -> RESET -> DISCO nRST
Rpi Pin 18 -> SWDIO -> DISCO PA13
Rpi Pin 22 -> SWCLK -> DISCO PA14
Rpi Pin 2 -> PWR -> DISCO 5V
Image may be NSFW. Clik here to view.
As you can see, no extra components are involved – only the target device, a power supply, RPi, and some wires.
Let’s start it up
The demo project is supposed to run the locally installed OpenOCD and use a regular wired setup.
Let’s create an alternate run configuration of the Embedded GDB Server type with the following parameters:
Target – select one from the list; by default there should only be one.
Executable – select one from the list; by default there should only be one.
Debugger – either bundled or from the ARM toolchain, whichever you prefer.
Target remote args – tcp::3333. The GDB server will try to connect to localhost, port 3333.
GDB server – path to your plink(Windows + putty) or ssh(Linux, MacOS)utility
Note that you have to use your own RPi IP address and password. Additionally, you may use a target configuration file that is not target/stm32f3x.cfg.
The GDB server args are the trickiest of these parameters. Let’s go over the various elements of them one by one.
-t reserves a pseudo-terminal for the utility started at Rpi (openocd).
-pw somepassword provides an ssh password. Use your own.
pi@your_rpi_ip_address provides the user name and IP address of the RPi board. Use your address.
-L 3333:127.0.0.1:3333 organizes an encrypted ssh tunnel. Local port 3333 at RPi board is transparently forwarded to port 3333 of the developer’s computer.
openocd -f rpi1-gpio.cfg -f target/stm32f3x.cfg starts openocd at RPi using our interface configuration and stm32f3 series kernel.
Now we have one last thing to set:
Advanced GDB Server Options -> Startup Delay – 1000 ms
Image may be NSFW. Clik here to view.
And we’re done! Just click the Debug button – the MCU firmware will be compiled and flashed, and the debugger session will start.
Image may be NSFW. Clik here to view.
Bonus Track – JTAG and RISC-V
Have you noticed that on the pinout hint some additional pins are marked with typical JTAG signals? This was intentional, as the JTAG interface is also supported. Let’s put that JTAG interface to use.
This script generates a JTAG config file:
cat <<EOF >~/rpi1-gpio-jtag.cfg
#
# Config for using Raspberry Pi's expansion header
#
# This is best used with a fast enough buffer but also
# is suitable for direct connection if the target voltage
# matches RPi's 3.3V and the cable is short enough.
#
# Do not forget the GND connection, pin 6 of the expansion header.
#
adapter driver bcm2835gpio
bcm2835gpio_peripheral_base 0x20000000
# Transition delay calculation: SPEED_COEFF/khz - SPEED_OFFSET
# These depend on system clock, calibrated for stock 700MHz
# bcm2835gpio_speed SPEED_COEFF SPEED_OFFSET
bcm2835gpio_speed_coeffs 113714 28
# Each of the JTAG lines need a gpio number set: tck tms tdi tdo
# Header pin numbers: 22 16 18 24
bcm2835gpio_jtag_nums 25 23 24 8
# If you define trst or srst, use appropriate reset_config
# Header pin number: 26
# bcm2835gpio_trst_num 7
# reset_config trst_only
# Header pin number: 12
bcm2835gpio_srst_num 18
reset_config srst_only srst_push_pull
# If you have both connected,
# reset_config trst_and_srst srst_push_pull
adapter speed 600
EOF
For this example, I’ve connected a Longan Nano board powered by a GD32VF103 chip, which is a RISC-V kernel and thus has no SWD interface.
I used a Risc-V toolchain, downloaded from the xPack repository. The bundled debugger does not support Risc-V, so we’ll have to use the toolchains debugger.
Image may be NSFW. Clik here to view.
Don’t forget to switch the toolchain on the CMake settings page
Image may be NSFW. Clik here to view.
At the time of this blog post’s composition (March 2021), the master branch OpenOCD does not support RISC-V chips particularly well, so OpenOCD should be cloned from a specific Risc-V fork and built as shown above.
The example project is located at GitHub, and the run configuration has already been created there. This run configuration for RISC-V MCU is very similar to the configuration for STM32F3 mentioned above, but it uses slightly different GDB server arguments that refer to a different transport and a different MCU:
Now all you need to do is set your own password and RPi network address.
Conclusion
Raspberry Pi is a very popular and easy-to-use single-board Linux computer. It is usually used for DIY projects. OpenOCD is an open-source program for flashing, debugging, and testing microcontrollers, including ARM and RISC-V kernels as well as many others. When used together with CLion, these resources make embedded development easier, more comfortable, and even safer in certain situations. The wireless setup described in this blog post is suitable for both hobby projects and professional ones.
A new CLion 2020.3.3 bug-fix update is now available!
Build 203.7717.62 is available for download from our website, via the Toolbox App, or as a snap (for Ubuntu). A patch update will be available shortly.
When loading a Makefile project, CLion now not only uses the make executable from the Makefile toolchain, but it also takes compilers from it (if configured explicitly in the corresponding toolchain). This improves the consistency and accuracy of our Makefile project support.
Debugger bug-fixes
A fix for the incorrect watchpoint types (CPP-9407), and also for watchpoint property changes which previously were not propagated to watchpoints.
A fix for the error during GDB pretty printers setup on MinGW-w64 (CPP-23244).
A fix for the bug causing EXC_BAD_ACCESS while debugging an app with Qt libraries on the new Apple Silicon (M1 chip).
CLion is also currently running the 2021.1 Early Access Program, and the builds for it are free to use. The recent changes include initial support for Makefile projects in remote mode, postfix completion for C and C++, branch coverage, dozens of new MISRA C and C++ checks, the integration of Clazy Analyzer, and more.
The newest CLion 2021.1 EAP build (211.6556.10) is now available. You can get it from our website, via the Toolbox App, or as a snap package (if you are using Ubuntu). Note that if you are on macOS, there is a separate build for Apple Silicon (M1 chip).
Modifying remote toolchain settings (for example, compilers) no longer resets the connection root path configured in the Deployment settings (CPP-22037).
Several BSD-like systems (OpenBSD, DragonFly BSD) were not working correctly as remote hosts, but now the problem has been fixed (CPP-24430).
In code completion:
Fixed an issue with completion not being available for delegating constructors (CPP-23345).
Fixed an issue with completion not being available for nested namespaces in type aliases (CPP-23909).
Fixed an issue with completion not being available for explicit after template (CPP-24029).
Back in October of last year I wrote "CLion Debugging – Part 1: Fundamentals", to introduce the everyday debugging features in CLion. It was "Part 1", because the promise was that I would follow up with a "Part 2", covering more advanced features. One thing you should never do is call something "Part 1" before you’ve written later parts!
Part 2 has been a long time coming not just because it was bigger than expected, but so much bigger that I am, in turn, splitting it into three parts! Therefore I’ve rebased on "Beyond the Basics – Part 1", and this part covers what you can do while you are suspended at a breakpoint, including some things you can do with expression evaluation that you may not have come across.
We’ll look at setting, muting and inspecting variables, evaluating expressions, adding watches, interactive inline hints (which was added since the previous video), hex and memory views, and the peripherals view for embedded devices.
Here are all the shortcuts used in the video:
Windows/ Linux
macOS
Command
F2
F2
Set Value
Alt+F8
⌥F8
Evaluate Expression
F4
⌘↓
Jump To Source
Ctrl+Alt+Shift+/
⌥⇧⌘/
Hex View
Ctrl+Enter
⌘⏎
Memory View
I’ll follow up with Parts 2 and 3 (which have been written). Part 2 will cover ways of suspending (break points and watch points) – including how you might not want to suspend at all – and moving the execution pointer. Then Part 3 will go beyond the immediate process to cover attaching to other (local) processes, debugging remote processes, debugging as root and debugging core dumps. It will also look at dropping to a GDB or LLDB terminal, as well as useing .gdbinit or .lldbinit to run debugger commands at the start of every session. Stay tuned!
Updating the toolchain used for your Makefile project now triggers a project reload.
Extracting the make targets for projects with a large number of them now works correctly.
For Makefile projects with the MinGW toolchain, CLion now handles directories with both backward (\) and forward slashes (/) correctly while loading the project.
For compilation database projects:
Clang-cl is now supported for such projects.
New MISRA C and C++ checks:
An exception object should not have the pointer type.
A few new checks now prohibit the usage of particular library functions, for example, bsearch and qsort of stdlib.h, the time handling functions of the ctime library, or atof, atoi and atol from the cstdlib library.
Following up on "Part 1: Suspended", of our Advanced Debugger series, Part 2 focuses on the dynamic part of working with breakpoints, watchpoints and setting the execution point. Because this an advanced series, we look beyond simply setting and removing breakpoints, and take a look at the different types of breakpoints we support, as well as all the options along with them. In many cases your breakpoints may not even need to break at all!
Watchpoints let you break when data changes – or even when it is read. And being able to skip over lines of code – or even go back – by setting the execution point, is a feature newly added just last year that really rounds out our debugging support.
Coming up next will be the third and final part of this series (or the fouth debugger video, overall), where we’ll look at lower level GDB and LLDB support, attaching to external, local, processes, remote debugging, debugging as root, and debugging core dumps.
The CLion 2021.1 release is just around the corner! Today we are ready to announce the CLion 2021.1 Release Candidate! Give it a go and make sure to report any problems you find to our issue tracker. We’ll try our best to sort out any pressing issues before the final release (though, in some cases the actual fixes might be postponed until the 2021.1.x bug-fix updates).
To install CLion 2021.1 RC (build 211.6693.66), download it from the website, update from our Toolbox App, or use this snap package (for Ubuntu).
Please note that you need to have an active subscription or a trial license to use CLion 2021.1 RC. No patches will be provided for this release candidate, but you can expect a patch to update the latest 2020.3 build to the 2021.1 release version.
It is time for our monthly C++ Annotated and its companion, the No Diagnostic Required show!
As you might know, we deliver this digest in a few different forms. You can choose to read, listen, or watch our essential digest of this month’s C++ news.
Read the digest published monthly on our blog (use the form on the right to subscribe to the whole blog).
Subscribe to C++ Annotated emails by filling out this form.
Watch the new episode of No Diagnostic Required below, or just keep reading this blog post for all the latest news!
Improving print logging with line pos info & modern C++
Print logging is still one of the most widely used methods for debugging and inspecting code. It’s also a place where we often use the macros in C and C++: __FILE__ and __LINE__. In this article, Bartlomiej Filipek discusses a few tricks on how to improve message scanning through the code in Visual Studio when the particular line is logged that way. A message in the predefined format "%file(%line): %msg" guarantees you can double-click on the line in the Visual Studio output window and navigate to the source code.
What if you’d like to eliminate macros from the approach entirely? It’s now possible with std::source_location in the C++20 standard! As of March 2021, std::source_location is available in Visual Studio 2019 16.10, and GCC 11. The new library type has constexpr calls for: line, column, file_name, and function_name. You can learn how to use it with this logging approach, in the same article.
If you are interested in the topic, feel free to read about Visual Studio Trace Points and check out what JetBrains CLion is capable of in terms of debugging techniques – such as non-suspending breakpoints, which allow you to log information without an actual break of the code execution.
GotW series by Herb Sutter: preconditions in some practical examples
The Guru of the Week series on Herb Sutter’s blog focuses on contracts – follow it for a lot of interesting information. We want to highlight one particular post from this series, which was published in March. This is the second part of a post dedicated to the preconditions topic, and it’s very practical with a “mental” exercise to find potential issues in the function declarations. How many ways could a caller of each function get the arguments wrong, but it would still silently compile without error? Herb discusses all the typical issues that may arise – the order of the arguments of the same type is wrong, the value passed is valid but out of range, and an invalid value is passed to a function.
It then goes into how you can improve and avoid some of the issues. You can group some of the parameters into a separate structure, use std:: pair, use an encapsulated class with invariants preserved inside the constructors, or rely on post-C++20 contract preconditions. The blog post discusses when to use each of the solutions and gives a handful samples explaining the differences. For example, is_sorted is much better as a function precondition, while not_null seems better as a type.
Language and committee news, from Phil
Contracts make an appearance in this month’s ISO mailing, too. This time it’s a new discussion document, D2339R0 – “Contract violation handlers” . The discussion is around what is allowed to happen in the handler that is called when a contract is violated. This is one of the most hotly debated aspects of the contracts proposals, and one of the reasons they were pulled from C++ 20, so it’s no surprise it is being given meticulous attention. On the face of it, the three choices seem simple enough:
It ends in calling std::terminate() or std::abort().
It ends by throwing an exception.
It returns normally (like a function that calls return;).
The debate primarily swirls around the last two choices, which have been pretty polarizing, and get right to the heart of what a contract actually is. This paper doesn’t make any recommendations, but rather tries to capture all the important points from all sides. It makes great use of the body of use cases that the SG21 study group – set up to discuss contracts in the wake of their prior removal – has been putting together. This really helps to put some flesh on each point and consider them together, rather than each person focusing on their own use case and pushing for a solution that caters to that. It even points out where some of these cases are in conflict. There’s also a great summary of some of the, still surprising effects of undefined behaviour, including the ability to remove belts-and-braces runtime checks just because a contract violation handler is allowed to return normally! Even if you don’t usually tend to read standards committee papers, you might want to try this one, as it reads more like an interesting blog post.
The term “Design By Committee” is usually used in a pejorative sense, and there are certainly some downsides when it comes to evolving C++. But to paraphrase famous closet C++ programmer, Sir Winston Churchill, “Standards committees are the worst form of programming language governance – except for all the others.” Where the committee really excels is deliberating on what things should be called! Back in January, we mentioned a revision to the Colony proposal, and recapped what the Colony container type actually is, as that name doesn’t immediately tell you (although it does make sense in retrospect). Since then, the hive mind of LEWG have also taken issue with the name, noting that, as a metaphor, it breaks down in some ways at some levels. The subsequent hunt for a new name eventually settled on Hive. Interestingly, the one weakness noted in the new name is that bees don’t actually live in the cells of a hive. As it happens, I used to live in Hythe, Kent, in the UK, so the metaphor works just fine for me! In any case, the whole adventure is documented in P2332R0 – “Establishing std::hive as replacement name for the proposed std::colony container”.
This mailing also included a number of proposals that were actually from WG14 (the C Language Working Group). As part of the C/ C++ liaison effort, delegates from the committees are getting together to identify proposals in one committee that may impact the other. One of the ones that came up this time, and seems to have strong support on both sides, is P2334R0 – “Add support for preprocessing directives elifdef and elifndef”. While you can achieve the same result with #ELSE and nested #IFDEFs, today, it was felt that using the dedicated directives would be more readable and less surprising. Personally, I think they sound a little like elves from The Lord of the Rings.
Russian Coat-Check Algorithm and Ticket Maps
At the recent ACCU 2021 Online conference, Sean Parent did a presentation on “Better Code: Relationships", where he described the Russian Coat-Check Algorithm, an example of coding a case when the program holds some data that’s associated with an ID value, monotonically increasing. Sean used it to prove the idea that relationships (between data and code) are important for many aspects, like performance or memory allocations. The talk from the ACCU Online event has not yet been published, but you can already check out some measurements and benefits of the structure discussed in the talk in Sean’s slides.
Anthony Williams later implemented the algorithm described by Sean and wrote a small blog post on it. Check it out here, and also find a link to the GitHub repo with the full code.
Keep Code Consistent with Syntax Style in ReSharper C++
Some code style choices are the developer’s personal preferences, some are set by general, company, or project guidelines. It’s often not that important how the particular style is structured, but it is important that it’s consistent throughout the entire codebase. In this case, tooling comes into play! It can help configuring and enforcing the style on the codebase and that’s exactly what the new settings in ReSharper C++ 2021.1 are about!
What exactly is configurable as part of the Syntax Style? You can choose when to enforce the usage of the auto keyword instead of the explicit type, whether const is east const or west const styled, and whether to use nested namespaces and trailing return types. There are style settings for including directives, initialization, and braces. All these new settings and the ability to enforce the configured style on your codebase is described in the blog post. Note, the feature is only now available in ReSharper C++ 2021.1 Beta, but the new release is just around the corner.
Branch and Line and Statement code coverage in CLion
CLion 2021.1 EAP has recently introduced Branch code coverage. This seems like a good time to talk about the various code coverage types and how different tools calculate it. In general, there are 3 types of coverage:
Line coverage – shows how many lines of your code (in %) were executed.
Statement coverage – shows how many statements of your code (in %) were executed.
Branch coverage – takes into account all the branches of each control structure.
GCC / gcov works in terms of line coverage, when compiled with the --coverage flag. Which means, for “return 0; int c;” you might get 100% coverage. This is not the case for LLVM / llvm-cov, which calculates statement coverage. This is something to remember when you use code coverage in CLion (which we call line coverage, by default).
The third type, branch coverage, was introduced recently. It takes into account all the branches of each control structure. For example, given an if statement, it can tell you if both the true and false branches have been executed. Interestingly there is again a difference between gcov and llvm-cov. GCC / gcov considers the compiler-generated branches when calculating branch coverage, while llvm-cov does not.
Conference news
It seems like virtual conferences will be with us forever, but two upcoming conferences are doing two different things about it.
The first is this year’s C++ on Sea, which has now announced dates, June 30–July 2. As we mentioned in January, there is a change of structure to better suit the online format, with more of an emphasis on workshop-based training while still having a whole day of more “traditional” conference content. Early-bird tickets are available, the call-for-speakers is open, and Barbara Geller and Ansel Sermersheim have been announced as keynote speakers (that’s one keynote – two speakers!).
The second is a new conference – C++ North is planning to run in Toronto, Canada in 2022. We’ve been thrown plenty of curveballs, so there are still no guarantees, but we are hopeful we will finally be able to meet in person by then. We’ll give more details on this as they emerge.
And finally: Will we ever get rid of macros in C++?
This gets asked from time to time, and has just come up again on Reddit. Every revision on the standard adds another set of nails in the coffin of the C++ preprocessor. But that’s a big coffin! It does feel like we’re almost there. With constexpr, in all its forms (including if constexpr), and source_location really closing the gap in the last two standards, it doesn’t seem like there is much left. Some in the Reddit thread point out that token pasting will always be a hold-out (although reflection may have some answers there). If you look at the implementation of the REQUIRE macro in Catch2 you’ll see that it expands to a lot of code. A lot of it could be replaced with a lambda – but this gets tried every few years, and so far the compile-time hit has always been too great! But surely that’s just a quality-of-implementation issue? If that could be done with source_location as well, it should be possible to go macro free (with some sacrifices). In fact Kris Jusiak’s UT library does just that!
Of course being able to write code without using macros, and being able to take macros out of the language are two very different things. I think we’re still going to be stuck with macros for a long time to come.
Nearly a year ago, our guest Nick Brook, founder at NRB Tech, explained how to use CLion for nRF52. Today, Nick is back with a new tutorial focused on using CMake-based nRF Connect SDK in CLion. Read this tutorial from Nick and give it a try with CLion!
Image may be NSFW. Clik here to view.
IoT consultant and founder at NRB Tech
Nick founded NRB Tech in 2018 to build useful and sustainable IoT (Internet of Things) products through a combination of in-depth hardware, software, and user experience expertise.
Previously, we established how it is possible to use Nordic’s nRF5 SDK with CMake and CLion. In April 2020, Nordic released version 1.0.0 of nRF Connect SDK, the new platform for Nordic products moving forward. This SDK is based on the Zephyr RTOS, a modern, secure, open source real-time operating system from the Linux Foundation backed by Facebook, Google, Intel, Nordic, NXP, and Opticon. The new SDK allows more complex projects using cellular and WiFi with new and future Nordic modules, while also supporting nRF52 series modules.
Zephyr uses CMake as its build system, making it much easier to use in CLion than the nRF5 SDK. However, there is some setup that we need to do.
Prerequisites
The nRF Connect SDK supports nRF52 series SOCs in addition to the newer nRF53 and nRF91 SOCs. All development kits and Thingy boards are supported. The nRF Connect SDK can be used on Windows, macOS, and Linux.
Setting up the toolchain and SDK
The best way to set up the SDK and toolchain on Windows and macOS is using the nRF Connect Toolchain Manager. This is the simplest way to get set up, and it also ensures that all toolchain dependencies are in one place and are the right versions for that SDK version.
Throughout this tutorial, when paths to the SDK are needed, we will use <ncsroot> as a placeholder. If using the Toolchain Manager with version 1.5.0, on Windows this would be C:\Users\<user>\ncs\v1.5.0; on macOS this would be /opt/nordic/ncs/v1.5.0.
Creating a custom project to use in CLion
Let’s create a custom project from a sample Nordic project.
Find a relevant sample from the SDK in the <ncsroot>/nrf/samples directory. Copy this to a convenient location on your system. Rename the directory if you wish. If you are very new to nRF52, the peripheral_hids_mouse example is recommended. The example simulates a regular computer mouse. For more details refer to the example’s README.rst file.
Open the project in CLion. Ignore any errors for now.
In CLion preferences, go to Build, Execution, Deployment | Toolchains and add a new toolchain. Configure as shown: Image may be NSFW. Clik here to view.
Name: “nRF Connect SDK <version>”, replacing <version> with the version of the SDK you are using
CMake: <ncsroot>/bin/cmake
C Compiler: <ncsroot>/bin/arm-none-eabi-gcc
C++ Compiler: <ncsroot>/bin/arm-none-eabi-g++
Debugger: <ncsroot>/bin/arm-none-eabi-gdb
Click “Apply”
In CLion preferences, go to Build, Execution, Deployment | CMake and then select the existing "Debug" profile.
Set Build type to ZDebug (this is explained further towards the end of the article)
Set Toolchain to the nRF Connect SDK <version> toolchain we just created
In CMake options add -G Ninja. Ninja is the recommended generator for Zephyr and prevents issues on Windows.
To provide Zephyr with the system and project specific configuration it needs, we must set the environment variables. We need to set the environment variables in the CLion profile because this propagates them to processes launched by CMake, so targets that use west will work. If we set the environment variables in CMakeLists.txt, they would not propagate to launched processes.
If you are using the toolchain manager, click the down arrow next to the NCS version installed and:
On Windows, click "Open command prompt" and paste:
Modify ZEPHYR_BASE, GIT_EXEC_PATH, and GNUARMEMB_TOOLCHAIN_PATH replacing <ncsroot>.
The NCS toolchain must come before other paths in the PATH variable. CLion does not yet support variable expansion in environment variables, so you need to enter the whole path, replacing <existing path>. To obtain the path to use, enter echo $PATH in a shell (macOS and Linux) or enter echo %PATH% in the command prompt (Windows).
If you want to use a board other than the nRF52 DK, you will need to modify the BOARD environment variable to the board you want to use. The boards available are defined here in the "Build target" column. There is also a webinar and guide you can follow to create a custom board. Image may be NSFW. Clik here to view.
Duplicate the "ZDebug" profile and modify the new profile’s "Build type" to "ZRelease". Click OK.
Most of the project configuration is done in the prj.conf file. Rename this file to prj.common.conf. This will contain the configuration common to both ZDebug and ZRelease builds. Open the file and at the bottom add:
# Use RTT instead of UART for debug output (optional)
CONFIG_USE_SEGGER_RTT=y
CONFIG_RTT_CONSOLE=y
CONFIG_UART_CONSOLE=n
Create a new file prj.ZDebug.conf and add:
# Optimize for debug
CONFIG_DEBUG_OPTIMIZATIONS=y
Create a new file prj.ZRelease.conf and add:
# Optimize for speed. See https://docs.zephyrproject.org/latest/reference/kconfig/choice_471.html#choice-471 for other options
CONFIG_SPEED_OPTIMIZATIONS=y
# Disable assertions in the Zephyr Kernel. This improves the execution speed and prevents a CMake configure warning. See https://docs.zephyrproject.org/latest/reference/kconfig/CONFIG_ASSERT.html
CONFIG_ASSERT=n
Open the CMakeLists.txt file. Before the find_package(Zephyr ...) line, insert:
if (NOT CMAKE_BUILD_TYPE)
set(CMAKE_BUILD_TYPE ZDebug)
endif()
# Point to the build type and common config files
set(CONF_FILE "prj.${CMAKE_BUILD_TYPE}.conf" "prj.common.conf")
Click Tools | CMake | Reset Cache and Reload Project.
You can now use the zephyr_final target to build <project dir>/cmake-build-<profile>/zephyr.hex, and the flash target to build and flash to the board.
Then select the Nordic SOC that you are using; the other defaults should be fine.
Next we will set up debugging.
On the top right of the CLion window, click the configuration drop-down and “Edit Configurations”. Then add a new “Embedded GDB Server” configuration: Image may be NSFW. Clik here to view.
Configure as shown: Image may be NSFW. Clik here to view.
Set a name
Check "Store as project file" to share this with other CLion users of your project
Note that you may need to adjust the -device parameter to match your device. A full list is available – select “Nordic Semi” from the drop down, and use the relevant “Device name” for this parameter.
To avoid a known issue with CLion/JLink GDB Server, you can work around it. Press Shift twice, type "registry", open the Registry, and change the "cidr.debugger.gdb.interrupt.signal" to "SIGTRAP".
Now you can build this target, which will build and flash, or you can debug. When debugging, if your breakpoint is not hit when the debugger starts, just click the reset button and continue: Image may be NSFW. Clik here to view.
You can also view the state of peripherals on the device when debugging. Click the "Peripherals" tab and click "Load .svd file": Image may be NSFW. Clik here to view.
Browse to <ncsroot>/modules/hal/nordic/nrfx/mdk and select the .svd file for your hardware (for nRF52832 use nrf52.svd), then select the peripherals you want to monitor. When the debugger is paused, you will then be able to inspect the values of peripheral registers: Image may be NSFW. Clik here to view.
In addition to using CLion for debugging, it’s sometimes useful to use Segger Embedded Studio (SES). This is Nordic’s officially supported IDE, so it is good to test with if you are having issues. In addition, when debugging you can see RTT output directly in the IDE with no configuration. With nRF Connect SDK, you can open your project just like any sample project by following the instructions in the guide.
As in Nordic’s tutorials, in this guide we used ZDebug and ZRelease build types. This avoids CMake using built-in defaults for C and C++ compiler flags, which conflict with the flags defined by Zephyr from KConfig. If you want to use the standard "Debug" and "Release" build types, for example if these are used by libraries you add to your project, you can. However, you must reset CMake’s default flags and disable the warning that Zephyr emits.
Open the CMakeLists.txt file. After the CONF_FILE line we added earlier, insert:
# CMake sets some default compiler flags in CMAKE_<LANG>_FLAGS_<CONFIG>. Zephyr sets all required flags from KConfig so
# clear CMake defaults to avoid any conflicts.
foreach(lang C CXX)
set(CMAKE_${lang}_FLAGS "")
foreach(type DEBUG RELEASE RELWITHDEBINFO MINSIZEREL)
set(CMAKE_${lang}_FLAGS_${type} "")
endforeach()
endforeach()
# Suppress a warning from Zephyr about a mismatch between CMAKE_<LANG>_FLAGS_<CONFIG> optimization flags (now empty) and
# Zephyr's KConfig optimization flags.
set(NO_BUILD_TYPE_WARNING ON)
In CMakeLists.txt change the default build type from ZDebug to Debug.
Rename prj.ZDebug.conf and prj.ZRelease.conf to prj.Debug.conf and prj.Release.conf
In CLion Settings/Preferences | Build, Execution, Deployment | CMake change the Build type of your profiles to Debug and Release.
We’ve now finished setting up a sample project in CLion for nRF Connect SDK development! To learn more about nRF Connect SDK development, you may want to explore:
Other samples in the nRF connect SDK:
<ncsroot>/nrf/samples/bluetooth – Bluetooth samples
The first release of the year, CLion 2021.1, is now available!
This new version provides an overhaul for code analysis, allowing it to catch more potential issues and guideline inconsistencies, enhances the debugging experience, and improves the capabilities of remote mode. In addition to the improved C and C++ experience, CLion 2021.1 introduces updated Rust and Swift support and valuable changes from the IntelliJ Platform.
To update to the new version, you can use the Toolbox App or a snap package (on Ubuntu), download the installer from our website, or apply the patch update to upgrade from the last 2020.3 build.
Catching issues as early as possible and checking your code against the guidelines is essential for improving code quality. An IDE can help with this task by running code inspections and highlighting potential issues on the fly in the code editor.
In CLion 2021.1 we’ve focused on improving the variety and accuracy of code analysis checks available to users in three main areas:
Including a global DFA (which takes a whole translation unit of a program as a single unit for analysis), in addition to the local DFA (which works within a single function).
Integrating Clazy, a Qt-oriented static code analyzer.
Introducing more checks from MISRA C 2012 and MISRA C++ 2008.
Let’s take a look at all three.
Data flow analysis (DFA) tracks the flow of data in your code and detects potential issues based on that analysis. It’s capable of detecting dangerous cases like dangling pointers, null dereferencing, or variables escaping their scope. CLion previously ran these checks locally, within the body of a single function. In v2021.1, CLion includes global DFA, which runs these inspections on translation units. This catches the same issues in a wider range of situations.
Image may be NSFW. Clik here to view.
Global DFA is not just an improvement to local DFA, it also makes it possible to run additional checks that are only possible in global mode:
Constant function result – reports functions whose return values appear to always be the same constant.
Constant parameter – reports functions where a parameter appears to always be the same constant.
Unreachable function calls – detects functions whose call sites are never executed.
Image may be NSFW. Clik here to view.
While introducing global DFA we reworked many of the underlined algorithms, which improved analysis performance. Read more about it in this separate blog post.
If you are working on a Qt-based project in CLion, you’ll be happy to learn that Clazy, a Qt-specific code analyzer, is now integrated into CLion’s Clangd-based engine. You’ll now get Clazy checks and quick-fixes right in the editor!
Image may be NSFW. Clik here to view.
The inspection severity level and the Clazy check level can be configured in Settings/Preferences | Editor | Inspections | C/C++ | General | Clazy.
To wrap up with the code analysis update in CLion 2021.1, we’d like to mention that we’ve added another pack of MISRA C 2012 and MISRA C++ 2008 checks. Not all checks are supported, but the improvement over the previous release is significant. The full list of available checks is maintained on our confluence page and allows you to easily track our progress.
Now it’s demo time! Watch a recent update to code analysis in CLion in this short video from Phil Nash, our developer advocate:
Enhancements for various project types
In addition to the new code analysis support we’ve added for Qt with the Clazy analyzer, we’ve also improved the Qt experience from a project model standpoint by implementing a small redesign for the New Qt UI Class dialog. You can now:
Specify the namespace.
Type a custom name for the parent class (previously you could only select from a few predefined options).
Image may be NSFW. Clik here to view.
If you are working on a Qt-based project, you’ll be interested in the Qt Creator keymap, which is now bundled into CLion.
We have continued to improve Makefile project support in CLion. In this release we’ve bundled the Makefile Language plugin (previously third-party), which provides syntax highlighting in Makefile, quick documentation, Find Usages for targets, and a variety of navigation and code completion actions. We’ve also started working on remote mode support for Makefile projects.
Image may be NSFW. Clik here to view.
It now works in a limited number of use cases. Makefile should be present in the project directory, and please note that if a pre-configure step is required, CLion can’t automate it for now. Check out the other limitations and known issues.
For CMake, we’ve added the ability to share CMake Profiles. Tick the Share setting in Settings/Preferences | Build, Execution, Deployment | CMake, and then commit cmake.xml to VCS:
Image may be NSFW. Clik here to view.
CLion 2021.1 also bundles CMake 3.19. This is the first CMake version to support Apple Silicon (M1 chip).
Whichever build system you are using, Project View gives you an overview of the files in your project. Source files located outside of the project root are now grouped under the External Sources node in the Project tree. This helps prevent the top-level crowding of these files.
Image may be NSFW. Clik here to view.
Time for another demo from Phil:
Open Project wizard
When you first get started with CLion or open a project for the first time in CLion, some additional configuration is often required. A new Open Project wizard is here to help!
The first step is the Toolchains configuration. It is shown only if CLion is being launched for the first time and settings were not imported. This step is essential, since no project can be opened and loaded in CLion without a toolchain configured.
The second step only appears for CMake projects, and it’s about CMake Profiles configuration. It is displayed if the project is opened for the first time (if the .idea directory is missing), if workspace.xml is missing from .idea, or if all the profiles are disabled. Of course, you can step back to the Toolchains configuration from CMake Profiles:
Image may be NSFW. Clik here to view.
Before you even see the wizard, CLion will ask you if you trust the project you are opening. The concept of trusted projects is designed to mitigate the risks associated with opening projects from unknown and untrusted sources. It’s a consequence of the approach that modern build systems are using, where they rely on code execution for building the project model that the IDE needs in order to understand the project structure and its dependencies. You can read more about the solution implemented in our IDEs in this blog post. Here’s what you’ll see in CLion when opening a CMake, Makefile, or Gradle project for the first time, for example from a VCS:
Image may be NSFW. Clik here to view.
Debugger
In CLion 2021.1, GDB and LLDB have reached feature parity for core dump debugging in CLion! To achieve this, we’ve added the ability to explicitly set symbol files when debugging a core dump for non-symbolized binary. Users can now also set sysroot in the corresponding run configuration. This will help localize library symbols when debugging core dumps from binaries built on other systems:
Image may be NSFW. Clik here to view.
The Set Execution Point action lets you jump to an arbitrary line of code in the editor during a debug session and is now available in the disassembly view.
Check out another demo from Phil on the debugger enhancements, as well as our new page fully dedicated to Debugger abilities in CLion.
Remote development and dynamic analysis tools
In addition to support for remote Makefile projects, CLion introduces a variety of further enhancements to remote mode! Dynamic analysis tools – Google Sanitizers, Valgrind Memcheck, and Code Coverage – now work with remote toolchains. And speaking of Code Coverage, CLion 2021.1 can now also calculate Branch Coverage in addition to line coverage. Let’s run unit tests with code coverage on a demo project remotely, from a local Mac to the remote Linux machine. The results can be inspected in the Coverage tool window:
Image may be NSFW. Clik here to view.
Branch coverage is enabled by default and can be adjusted in Settings/Preferences | Build, Execution, Deployment | Coverage, but it only works with GCC/gcov or version 12.0.0 and higher of LLVM/llvm-cov. Read more in this blog post.
When you work with remote projects, you might need to adjust something manually or check the remote directory containing your project. There is a remote terminal in the IDE and a new Tools | Open Remote Host Terminal action that directly opens the project directory on the remote host.
We also would like to mention Code With Me, the new built-in service for remote collaborative development and pair programming. Code With Me connects remote teams in a feature-rich collaborative environment and helps boost productivity, no matter where the team members are based. The essential IDE features, such as smart code insight, navigation, remote unit testing, and debugging, are available for participants during collaborative sessions. Teams can simultaneously edit code, track changes with diff previews, and follow each other in the shared project. The embedded audio and video calls, along with chat messaging, help software developers discuss the code, share their knowledge, and cooperate more efficiently.
For those who must follow strict security policies, Code With Me has an on-premises version. The service can be installed and run securely on the company’s own private network. To learn more about the availability of Code With Me with your current JetBrains license, check out the pricing page.
Postfix completion for C and C++
Sometimes you may want to type a collection and then wrap it with the for loop to iterate through it. Or you may need to get a type and then create a shared or unique pointer of this type, or wrap a given expression with one of the C++ style casts. In all these scenarios, you can start with an expression and then wrap it with some “action”, which is represented by a language construct, even though the “action” goes first in the final code. CLion 2021.1 introduces postfix completion for C and C++ to support this approach to coding.
Image may be NSFW. Clik here to view.
You will find a long list of postfix templates that work this way in Settings/Preferences | Editor | General | Postfix Completion.
If you miss the Uniform Function Call Syntax (UFCS) in C and C++, the new postfix completion feature offers a very similar experience. You can use postfix code completion to pass the expression you’ve just typed to a free function as the first argument:
By the way, this feature isn’t new in our C++ tools. In ReSharper C++, our C++ extension for Visual Studio, we also have a similar postfix completion ability.
VCS support enhancements
There are a bunch of updates coming to CLion from the IntelliJ Platform. This includes a number of VCS support enhancements:
Code inspection profiles that you can select to execute before committing changes to VCS
Support for custom commit message templates in Git
A new Save to Shelf action (which allows you to copy your changes to the Shelf while keeping them in the local changes)
Rust and Swift plugin updates
The IntelliJ Rust plugin team has prepared a lot of fixes and improvements, which they will post separately soon after the official CLion 2021.1 release. We just want to take a moment to highlight the new structured view for the compiler’s build output, the new Change Signature refactoring, updates to the Rename refactoring, and the ability to use Find Usages for Cargo features. Stay tuned for a more detailed update!
Thanks to the AppCode team, the Swift plugin is now available in CLion on Windows! You can find a few tips on how to get the toolchain, as well as information about some known issues, in this blog post.
That’s it! We encourage you to give CLion 2021.1 a try. Update today if you have an active subscription, or start your free 30-day trial to evaluate the new features!
A new CLion 2020.3.4 bug-fix update is now available!
Build 203.8084.11 is available for download from our website, via the Toolbox App, or as a snap (for Ubuntu). A patch update will be available shortly.
In this update we’ve fixed an issue with Compilation Database projects that caused the Build tool window not to be displayed when a project was reloaded using the editor widget. In addition, we’ve ported the trusted project functionality released earlier as part of CLion 2021.1.
Project security and trusted project notification
Obtaining a project from unknown or untrusted sources can raise serious security concerns. To prevent potential security risks, CLion (like other JetBrains IDEs) warns you about tasks or configurations that will be executed during the opening or cloning process, and it lets you specify which sources you trust.
When you open a CMake, Makefile, or Gradle Native project in CLion, the IDE executes the build script during the loading process, and this script could potentially contain untrusted code. When you try to open a project from an unknown source for the first time, CLion displays a warning and lets you decide how to proceed:
A bug-fix update for CLion 2021.1 is now available.
The first bug-fix update (build 211.7142.21) for the recently released CLion v2021.1 is now available on our website, via the patch-update, in the Toolbox App, or as a snap (for Ubuntu).
Fixed the regression that resulted in slow code completion (CPP-24744).
Fixed the problem with compiler information collection failing and leading to code assistance not working (CPP-24777). The problem occurred if PCH files were passed via “--include=...”.
Fixed the problem with corrupted indexes that caused Find In Files to show no results (IDEA-266391).
Added a new intention to add/remove braces in if, for, while, and do-while statements.
Clangd fixes:
Fixed a problem with Clangd settings that failed to open in some cases (CPP-24742).
Fixed an issue with Clangd greedily allocating all the memory and freezing the system.
For CUDA projects:
Fixed the regression that caused the broken syntax highlighting (CPP-24756) and incorrect compiler information collection (CPP-24802) on CUDA projects.
CLion now uses the gcc compiler from CUDA installation, if it is installed.
We’ve added a few new MISRA checks and fixed a Clangd crash caused by MISRA-related code analysis.
For remote projects:
CLion no longer ignores the clion.remote.resync.system.cache registry flag for Makefile projects (the flag specifies if CLion should always re-sync header roots upon project reload) and the Resync with Remote Hosts action is now also available for Makefile projects.
If there are directories on a remote host containing files that the remote toolchain user does not have read access to, the synchronization doesn’t fail now and CLion still tries to synchronize at least the files that the user can access (CPP-24792).
Fixed an issue with ASCII combination (Alt + Numpad) entered in the editor but not working as expected (IDEA-260888).
Fixed the modal dialog freezes on macOS Big Sur (IDEA-256329).
New plugins
A few new plugins were bundled into this version. Grazie provides intelligent spelling and grammar checks for text that you write in the IDE. To use it in C++ files, turn the grammar checks on in Settings/Preferences | Editor | Proofreading | Grammar:
Image may be NSFW. Clik here to view.
To add consistent copyright notices throughout your codebase, rely on the Copyright plugin. Find the settings in Settings/Preferences | Editor | Copyright. Learn more in our webhelp.
CLion 2021.1 is now released along with the first bug-fix update 2021.1.1 addressing some of the most critical issues which unfortunately squeezed through our testing procedures. We do hope you are enjoying the update now and giving the new data flow analysis, Makefile and dynamic analysis in remote mode, and C/C++ postfix completion a try. We are listening to your feedback carefully and planning the upcoming bug-fix updates accordingly. It’s also time to move forward and see what CLion 2021.2 may look like!
Special thanks
Before we talk about the plans for the next release, let us first thank all participants of our Early Access Program! We are super grateful for every piece of feedback reported to us as it helps us polish and fine-tune the final release in many environments. And as a special thank you to the most active EAPers, we provide them with a complimentary 1-year CLion subscription!
Victor Sergienko
Tom Evers
Natalia Portillo
We’ll email you in the next few days with a code for buying a new subscription or extending your current one. The code can be passed on to a friend or colleague, too.
Roadmap for CLion 2021.2
Our priorities for 2021 and main directions for this year are still unchanged:
Performance and responsiveness.
Better C++ language engine.
Quality and feature-parity throughout toolchains and project models.
Bringing new value to embedded / automotive / remote workflows.
As for the 2021.2 update, we plan it somewhere late July – early August. And here is what we will be working on during this release cycle:
Please note the following is only a preliminary plan, as some tasks will only be started but might not be finalized until after the actual release, or might be changed or rescheduled for various reasons. We cannot guarantee that all of the features listed below will be included in CLion 2021.2.
C++ language support
Top priority here is still bug-fixing and addressing performance issues, especially freezes.
Custom compiler – a way to specify supported features, header search paths, defines etc. if the compiler is not supported natively by CLion (CPP-9615).
Fixing issues with MSVC toolchain when CLion fails to get compiler information correctly.
Project models
Pre-configure step for Makefile projects (CPP-16924).
File templates for CMakeLists.txt (CPP-547) and main.cpp (CPP-5089) files.
Finally, we plan to start diving into CMake presets but the full support won’t be delivered in 2021.2 (CPP-22906).
Remote mode
WSL: support distributions installed by a custom path (CPP-11841).
WSL: remove running processes in WSL via ssh to significantly simplify WSL toolchain configuration in CLion.
We also plan to skip source synchronization in case of Docker to address issues like CPP-14315.
And finally, we’ll start adopting the IntelliJ-platform feature called Run Targets, which in case of CLion might help addressing the case when you are developing in one remote environment (e.g. Docker) and run/debug in another (e.g. embedded device).
Debugger. There is now a huge underline work going on in the heart of the debugger integration in CLion. It will result in significant UX improvements likely this year but it’s hard to name specific tasks for 2021.2 iteration. In other plans:
Please welcome the April edition of C++ Annotated and its companion, the No Diagnostic Required show!
As you might know, we deliver this digest in a few different forms. You can choose to read, listen, or watch our essential digest of this month’s C++ news:
Read the digest published monthly on our blog (use the form on the right to subscribe to the whole blog).
Subscribe to C++ Annotated emails by filling out this form.
Listen to our podcast – just search for “No Diagnostic Required” in your favorite podcast player (see the list of supported players).
April news
Language news:
P0323: std::expected
P2128: multidimensional subscript operator
P2321: zip
P2358: defining contracts
Release time:
CLion 2021.1 release and 2021.2 roadmap
ReSharper 2021.1 release and a brand-new Rider for Unreal Engine on macOS
GCC 11 with C++ modules
CUDA support in Visual Studio Code
Conferences
Pure Virtual C++
C++Now
C++ Foundation annual survey results
And finally, what is possible in modern C++ that wasn’t in C++98
Watch the new episode of No Diagnostic Required below, or just keep reading this blog post for all the latest news!
Language news
As usual, we’ve picked a few proposals from this month’s committee mailing to highlight. As these are all at various stages of being discussed in the committee, there are no guarantees they will make it into a future standard, but some of them are definitely… expected!
This proposal is now on R10 – the first version was back in 2016 – and it’s not even the first time we’ve discussed it here. But R9 was back in 2019, so what’s changed since then?
In terms of design, and even wording, not much. The primary change is that, whereas R9 was based on the Library Fundamentals TS, the direction from LEWG (the Library Evolution Working Group) is that it should target the IS (the main standard) instead. There was quite a strong consensus, which shows that this is considered an important vocabulary type. Hopefully this is reassuring to those that were disheartened when std::expected didn’t make it into C++20. That was just because it didn’t get through wording in time, rather than being voted against – so it should, hopefully, have a smooth run into C++23.
My hope is that it gets voted into the working draft soon enough that we can consider adding monadic operations to it, too, along the lines already proposed for std::optional.
But what is std::expected? It’s a choice type, along the lines of std::variant, but specialized for return types and error handling. In the “expected’ (happy path) case, a value of a normal return type is held. But if an error prevents that type from being returned, then a value of the error type can be supplied, instead. Ergonomically it works much like std::optional, but with the ability to carry the error value in the “unexpected” case. For a bit more about it, including those potential monadic operations – as well as some of the other proposals relating to error handling in C++ – see my talk, Dawn of a New Error.
Something else that’s expected, but perhaps sooner than expected, is this proposal for extending the subscript operator, [], with multiple arguments. Why expected? Because, to lay the groundwork for this, we deprecated use of the comma operator within the subscript operator in C++20. Why sooner than expected? Because this proposal includes removing comma operator support. That’s a very rapid turnaround! For comparison, auto_ptr was deprecated in C++11 (although, spiritually, it was deprecated in the community long before that), then removed in C++17 – and that was seen as quite fast! However, while auto_ptr was widely used in older code, being a fundamental vocabulary type in C++98, use of the comma operator within the subscript operator is quite rare.
But why do we need this ability? Right now, libraries that define types for things like multidimensional arrays, matrices, grids, etc. (including types in the standard library, like mdspan and mdarray), tend to resort to overloading the call operator instead. While this works – indeed the usage would be exactly the same – it’s a compromise. As the paper claims, it doesn’t convey the intention as clearly.
Continuing the trend of proposing library features that augment C++20 features which we didn’t have the time, or the scope, to get into C++20 itself: this month we have zip. Actually R0 came in February, but we didn’t discuss it then, and now R1 is here, anyway.
Zipping is a facility found in many languages that deal with range-like features. It allows you to combine two or more ranges into a single range view where each element is a tuple – with one item from each of the original ranges.
A common example is when you want to iterate, say, a vector, but you also want to have access to the index into the vector. Of course you could do that by using a classic, C-style, for loop – and index into the vector within the body. But that gives up many of the benefits of range-based for loops, and it may not be possible at all if you’re using algorithms. However, if you can generate a view of an increasing counter, say with std::ranges::views::iota, you can iterate the zip of that and the vector itself and get both the value and the element on each iteration. In practice there are some issues with using iota in this way, in the general case, so a more specialized facility, std::ranges::views::enumerate, is proposed as P2164 (which also makes it more convenient).
The design discussion around zip itself and its sibling facilities (zip_transform, adjacent and adjacent_transform) – as well as enumerate – are covered by reference to an earlier paper, P2214: A Plan for C++23 Ranges.
This is another paper that distills some of the ongoing discussion in SG21 – the contracts study group. Last time we mentioned that one of the problems with the original discussion of contracts – leading up to their removal from C++20 – was a lack of common ground between parties with different interests. SG21 has discovered the hard way that there has been a lack of agreement on the definitions of terms being used to describe use cases. So this paper is an attempt to bring some much-needed clarity by setting out specific definitions on many of the terms commonly used in contracts discussion. The paper even starts out, after an appropriate quote from Humpty Dumpty, by saying, “This paper defines terms so that the SG21 group doesn’t talk past each other”! It’s a short but information-dense paper that’s well worth a read if you want to see how deep the rabbit hole goes.
Releases
CLion 2021.1 release and the 2021.2 roadmap
CLion 2021.1 was released in the first week of April. The main focus of this first major update in 2021 is code analysis, enhancements for support project models, and feature parity in remote development and in the debugger. If you asked me to name the top 3 benefits of this release, I would say:
Postfix completion for C and C++. With it, you can pass the expression you’ve just typed to a free function as the first argument. You will especially like it if you miss Uniform Function Call Syntax (UFCS) in C and C++.
Global data flow analysis. It will capture things like dangling pointers and null pointers dereferencing for you within whole translation units, not just within function bodies as it did before.
Branch coverage (in addition to the existing statement coverage) and dynamic analysis are now available in remote mode.
Also worth mentioning are new MISRA checks for embedded developers, Clazy for Qt projects, remote Makefile projects, and Code With Me, a new JetBrains service for collaborative development and pair programming.
If you are interested to know what’s coming next to CLion, the preliminary roadmap for 2021.2 is now available. It includes, among other things, Lifetime analysis, custom compiler support, initial work on CMake presets, more goodies for embedded developers, and much more.
ReSharper 2021.1 release and Rider for Unreal Engine on macOS
Version 2021.1 of ReSharper C++, our extension for Visual Studio for C++ developers, was also released in April. The biggest change is Syntax Style settings with accompanying inspections, quick-fixes, and context actions – we talked about them in March already. This update also delivered the following enhancements:
Many new C++20 additions, like class types in non-type template parameters, new CTAD rules, and coroutine-related syntax in regular and postfix code completion.
Initial support for Unreal Engine 5 and other UE-specific additions for those who create games in Visual Studio with ReSharper C++.
New code analysis checks that keep the code simpler by finding things like redundant template arguments or redundant cast expressions.
Speaking of game development with Unreal Engine, JetBrains Rider for Unreal Engine, which is in preview for now, has announced a macOS version. Mac users can now get the same smart UE support that Windows users of JetBrains Rider or ReSharper C++ have been benefiting from for the past year.
GCC 11
Wondering how major compilers are doing these days? GCC and Clang both have major updates! GCC 11 is finally delivering C++20 modules support, still with some incompleteness, and it requires the -fmodules-ts compilation flag to be passed. There are more C++20 additions in this release and even some additional C++23 draft features, along with C++20/C++23 changes to the libstdc++ library. Additionally, the new version defaults to -std=gnu++17 instead of -std=gnu++14. This might cause some porting issues, so do make sure you’ve read the Porting to GCC 11 article if you are on GCC.
CUDA support in Visual Studio Code
Microsoft and NVIDIA have partnered together to work on better CUDA support in Visual Studio Code. This was announced in both NVIDIA and Microsoft blog posts.
IntelliSense for CUDA kernel functions is available now in VS Code Insiders (preview) builds. But it’s also part of a bigger effort, NVIDIA Nsight Visual Studio Code Edition. The latter additionally promises build and debug support for GPU kernels, including:
Standard breakpoints and stepping abilities for CPU and GPU code.
Conditional breakpoints with expression evaluation.
Call-stack, register, and variable views.
Builds are not yet publicly available, but you can fill out a form on the NVIDIA site to show them you’re interested in the preview.
Conferences
Pure Virtual C++
Microsoft announced a free one-day virtual conference for the C++ community. It will run on May 3 and will include pre-recorded sessions with a live Q&A with each speaker. The program targets the most recent additions to Microsoft tooling and shows Microsoft particular interest in several important community topics:
Two talks on C++ Modules, explaining visibility and reachability concepts, and giving an overall recap of where we are now with the real usage for C++ Modules in practice.
A collaborative talk with Kitware on their brand-new CMake presets feature.
As the biggest pain-point in C++ is managing dependencies, an update on vcpkg will be presented.
Static and runtime analysis (AddressSanitizer) tooling for better C++ code quality.
C++Now
C++Now Online 2021 will be running May 2 – May 7, and the program is already available on the conference website, with keynote sessions from:
Bill Hoffman, founder of Kitware, the company behind CMake. No surprise, Bill will be talking about this build system (the talk is called CMake: One Tool To Build Them All), the most popular project model in the C++ ecosystem right now. The keynote session will cover the history behind it and its most important modern features, and hopefully will give a first-hand account of the main philosophy behind the technology.
Bryce Adelstein Lelbach, NVIDIA’s HPC Programming Models Architect and chair of the Standard C++ Library Evolution working group. In his talk, Bryce will share the principles that are shaping the evolution of the C++ Standard Library. Hopefully he will answer the question that’s bothering many C++ developers who are following the evolution of the language: what should go into the STL and what should not?
Tony Van Eerd, undoubtedly the best presenter in the C++ community (and beyond) and author of the famous Tony Tables approach, which uses examples to explain how changes to the language transform the code. Tony’s keynote is dedicated to SOLID Principles, which are celebrating their 20th birthday! If you are still not aware of what the acronym stands for, this talk will give you an answer and will also discuss how it fits into modern C++.
Phil Nash and I are also giving talks at C++Now this year. Mine is on code analysis for C++ in its modern shape and form (Code Analysis++). And Phil will join Eduardo Madrid to talk about Polymorphism, with comparisons and examples from Swift, Rust, Objective-C, and JavaScript.
C++ Foundation annual survey results
The Standard C++ Foundation has published the results of their annual survey for 2021. The goal of the research is to understand the C++ community better by collecting information about the areas of development, experience, preferences for language standards and tools, main pain-points, and C++-related habits.
It’s no surprise that one of the major causes of frustration for developers is managing libraries their application depends on. Package and dependency managers are still far from being standard tooling in C++ – despite such strong players as Conan and vcpkg. That’s why “The library source code is part of my build” is a true statement for nearly 69% of respondents, while Conan and vcpkg get about 16% and 15% respectively. CMake is a build system of choice for nearly 80% of respondents, and at the same time managing CMake projects is super-problematic for a bit less than 32%.
And of course, the most frequently asked question is about the C++ standard. Just 40% of respondents are allowed to use C++20, whereas four out of five can use C++17. But the most promising result is that in the next 12 months:
46% plan to allow the usage of Concepts in their products
36% plan to allow Coroutines
38% plan to allow Modules
Interestingly, most of the collected responses came from developers with 10+ years of experience in C++, which means the audience is very experienced and probably highly skilled. We usually keep this in mind when comparing the results of our Developer Ecosystem research against the C++ Foundation survey results. In our survey the C++ audience has slightly less experience in C++ (1-5 years for the majority of the audience). By the way, the results of the JetBrains Developer Ecosystem survey for 2021 should be going live in June, so stay tuned!
And finally, what is possible in modern C++ that wasn’t in C++98
This Reddit thread re-ignited an age-old argument: isn’t any programming language, no matter how advanced, just syntactic sugar over earlier versions of the same language, possibly all the way back to assembler? There’s some truth to that, but one interesting point emerged from the discussion: a systems language is a point of interface between application code and the operating system it runs on (assuming an OS). In some cases, the way the language is defined makes it impossible to do certain things without language support. The example that comes up a lot in the thread is of the C++ memory model, which was very under-defined prior to C++11 – especially with regard to threading. That threading libraries existed, and appeared to work, was not guaranteed by the standard at all – and writing reliable threading code portably was fraught!
Another interesting point raised was that move semantics allow you to write generic code that wouldn’t have been possible before, because there was no way to distinguish between an lvalue and an rvalue.
Of course many of the changes that have come in C++11, and beyond, while technically syntactic sugar over facilities we had before, were so dramatic in the level of convenience they brought that they were often impractical before, even if not impossible. Lambdas are a good example. Variadic templates must rank up there quite highly for anyone who had to do them the long way round before C++11!
In this video we start by looking a direct access to the GDB or LLDB terminal, as well as running commands on start-up using .gdbinit or .lldbinit, then look at attaching to external processes and debugging on remote machines. We also look at debugging core dumps and running the debugger with root privileges.
We hope you have enjoyed this series and have learnt some ways to make your debugging more productive.
The CLion 2021.2 EAP program has now begun! The first EAP build is ready for you to try out. If you want to know what we are working on in particular during this release cycle, please read this roadmap blog post.
Image may be NSFW. Clik here to view.
EAP builds are free to use, but might be unstable and of lower quality. The main goal of these builds is to let our users evaluate the features which will be added to the next release and share their feedback at early stages. These builds also can be used to test the changes in rare and very specific environments, which are hard to cover from our side.
Build 212.3116.34 is available from our website via the Toolbox App, or as a snap package (if you are using Ubuntu). Note that if you are on macOS, there is a separate build for Apple Silicon (M1 chip).
CMake 3.20 is now supported and bundled in CLion. This version includes CMake Presets, major updates to CMake File API, support for C++23 compiler modes, and many updates for CUDA developers.
CMake Presets
CMake Presets are a new way to configure CMake options and share them with others. It’s all thanks to two files:
CMakePresets.json is meant to save project-wide builds, and may be checked into VCS.
CMakeUserPresets.json is meant for developers to save their own local builds, and should not be checked into VCS.
CLion, on the other hand, operates with CMake Profiles – entities which are specific to CLion but have many settings in common with the CMake Presets and are also shareable via VCS. The major difference is that they reference CLion toolchains, which shouldn’t be mixed with the CMake toolchains. They serve different purposes and CMake toolchains can’t cover CLion use cases. The CLion toolchain serves other project models and contains information that is not present and not needed in the CMake toolchain, like the debugger and environment settings (remote host, WSL, etc.).
Now that we’ve explained the difference, we’d like to announce that CLion now supports importing information from CMake Presets. This is just the first step toward CMake Presets support in CLion and we are eager to hear your feedback on how we are doing.
The Load CMake Presets action (use Find Action via Ctrl+Shift+A/⇧⌘A to find it by name) searches through the existing Build Presets and shows them in the popup: Image may be NSFW. Clik here to view.
When selected, CMake Preset is imported into CLion CMake Profiles read-only mode. You can review the list of profiles in Settings/Preferences | Build, Execution, Deployment | CMake. Image may be NSFW. Clik here to view.
Known limitations and further plans:
Imported presets are read-only. However, you can open the corresponding JSON files, edit them in CLion, save the file (currently, autosave is not supported – CPP-25076) and reload the preset in CLion.
CLion at present supports only version 2 presets and only buildPresets.
After importing, CMake Preset in CLion gets a link to the CLion toolchain. For now, it’s the Default toolchain, but later we’ll provide a way to configure it.
The general task for supporting CMake Presets in CLion is much wider (CPP-22906) and will likely include a way to update presets from CLion UI.
CMake Project Templates
In addition to the CMakeList.txt file template for a new file, CLion now also provides editable templates for new CMake projects. You can find them in Settings/Preferences | Editor | File and Code Templates | Other: Image may be NSFW. Clik here to view.
C and C++ libraries and executables, CUDA libraries and executables, and Qt projects are available there. These templates are used when you create a new project via the File | New Project wizard.
CMake targets as Before Launch tasks
In the Before Launch section of the Run/Debug configuration, users can specify the tasks to be performed before starting the selected target. By default, there is a Build step there. You can now add a CMake Target task in this phase to execute the CMake target: Image may be NSFW. Clik here to view.
Both built-in (like for example, all, clean, install) and user-specified (created via add_executable or add_custom_target) targets will be suggested: Image may be NSFW. Clik here to view. Learn more
Lifetimes analysis
According to the C++ Foundation Developer Survey, memory safety issues like use-after-free/delete are among the top points of frustration for C++ developers. The Lifetime Safety proposal is trying to address these issues in the C++ language. The idea is to diagnose common cases of dangling pointers and references (use-after-free, use-after-move) at compile time, by using local analysis. Local analysis uses the concepts of Owners, Shared Owners, and Pointers. The GSL library brings annotations to mark the code and help local analysis.
The proposal is still under discussion, but there is an experimental Clang branch supporting some ideas from the proposal, and Today Lifetime analysis comes to CLion!
For example, here CLion warns you about the string view referencing an invalid object after the temporary string is destroyed: Image may be NSFW. Clik here to view.
Various cases of local variables pointing to memory which is out of scope are also caught by CLion: Image may be NSFW. Clik here to view.
GSL annotations are also supported in the analysis: Image may be NSFW. Clik here to view.
The analysis runs in the scope of the function body. While it doesn’t catch all the issues, it can already help significantly with one of the most troubling C++ issues.
Cling Support
You might not expect it, but there is an interactive C++ interpreter, Cling (check out its GitHub page), built on top of Clang and LLVM. It’s really useful for prototyping and learning C++. You can find a short video here which explains the basics of working with Cling.
With this EAP, Cling is now supported in CLion! To start with Cling in CLion, download the cling executable for your platform or install it via your OS-specific dependency manager (like brew on macOS), and configure a path to it in Settings/Preferences | Languages & Frameworks | C/C++ | Cling. It will be autodetected by CLion if Cling is in PATH.
You are ready to go! In the Tools menu, you will find the related Cling actions, or you can call them from Find Action. Image may be NSFW. Clik here to view.
For lines of code, an intention is available that sends the current line to the Cling session: Image may be NSFW. Clik here to view.
You can select several lines, press Alt+Enter, and send the whole selection to Cling. You can also just load a whole file to Cling, or simply type code directly in the Cling terminal: Image may be NSFW. Clik here to view.
There are a few known limitations worth mentioning:
Users can’t add extra arguments to the Cling executable starting from within CLion for now, so you can’t really change the C++ language standard or other options.
Project flags are not passed to the Cling session (CPP-25256). This might cause an issue with some included paths not known to Cling.
The Cling session is started within the project directory or within the home directory (if no project is currently open). The relative paths might not be handled correctly when sending a current line to Cling from a file that is not in the project root..
WSL enhancements
You no longer need an SSH server inside a WSL distribution to work with WSL in CLion. WSL processes are now started using a dedicated WSL API, making WSL configuration in CLion much easier.
CLion now supports WSL installed not only from the Microsoft Store, but also from custom distributions. The IDE shows all imported WSL distributions in the drop-down list on the dedicated Toolchains settings page (the list is the same as the one returned by the wsl -l -v command).
Text search in Local History
If your project is not under version control, you are still safe from any bad changes (like deleted files). With Local History you can roll back to any past state of a file, even if no version control is enabled for your project. It allows text search through the file revisions so that you can locate the point you want to rollback to more easily.
And more
This build addresses several IDE freezes, specifically related to copy-pasting activities.
A few new MISRA checks are added.
Starting from this EAP, it is possible to navigate back and forth between open sections in Preferences/Settings. To do so, use the arrows in the right-hand corner of the window.
The difference between the initial and changed files is now always displayed in the editor, regardless of how you invoke the Show Diff action. If you find it more convenient to track changes in a separate window, you can drag the desired file from the editor. If you do, the IDE will remember this and will open future diffs in a separate window.
It’s now easier to code with the enabled screen reader mode on macOS – a list of available suggestions for code completion is now read out loud.
Please welcome the May edition of C++ Annotated and its companion, the No Diagnostic Required show!
If you are already subscribed, feel free to skip to the news. If you are new, though, you are welcome to explore all the formats we offer. Choose to read, listen, or watch our essential digest of this month’s C++ news:
Read the digest published monthly on our blog (use the form on the right to subscribe to the whole blog).
Subscribe to C++ Annotated emails by filling out this form.
Other languages with optional types tend to also have ways to compose code using them in well-defined ways. These ways are often known as the Monadic Operations, but you don’t have to understand monads to benefit from them. I won’t repeat the code samples, as we talked about this last month in the context of std::expected, but this month has seen some activity on the original std::optional version, too. To summarize, the result is that a significant amount of boiler plate code and indentation is eliminated and the flow of data through the code is much clearer.
The changes in this revision are fairly minor, with wording tweaks, adding constraints, and some little tidy-ups for consistency. This is reassuring, as it seems the design is in good shape and we’re getting ready to poll it for inclusion into the working draft. We’re hopeful, as this is an important component of an overall alternative error-handling strategy that is emerging for C++.
[[nodiscard]] in the Standard Library: Clause 23 Iterators library – P2377
Continuing that error-handling theme, although by no means limited to error-handling, [[nodiscard]] was introduced in C++17 as a way to inform both the user and compiler that a return value is an important or essential part of a function call and that ignoring it is probably a mistake. Compilers are not required to issue a warning, but are encouraged to do so. While this seems like a great idea – and would even have been better as a default, as the paper mentions – it hasn’t been applied extensively to the standard library itself. Doing so requires going through the library on a case by case basis to see what makes sense and what can be done without breaking valid code. This proposal is doing just that for the iterators library (so not really about error handling per se).
There was a late request to do so as part of C++20, but there were some cases, particularly around CPOs (Customization Point Objects), that weren’t clear cut and had to be postponed until later. Later has now come, and there is a section in the paper dedicated to CPOs with a few options, including one that results in “No Diagnostic Required”!
[[nodiscard]] has relevance to error handling when errors are propagated via return values (error codes, optionals, variants or the proposed std::expected). Error codes can be handled via switch statements, but for the more complex “sum types”, the handling quickly gets much more verbose (hence the monadic operations proposed for std::optional). Another way to cut through this is to use pattern matching in languages that support it. C++ may become such a language, as the pattern matching proposal continues to evolve. But in the context of error handling, if errors are propagated via exceptions, the syntax looks different, even if there are structural similarities. This paper proposes to lean into that and allow exceptions to be handled directly as part of the pattern matching syntax. That way, whether you use exceptions, error codes, or std::optional/ std::expected, the handling will look much the same.
This is definitely an interesting proposal, and I have some sympathy for the idea. I doubt it will be without controversy as it gets discussed. We’ll see where it goes.
Speaking of interesting, yet controversial, proposals to keep an eye on – let’s turn the dial up to 11! ABI compatibility – in the sense of whether code built with one version of the standard (especially the standard library) can link against the next – has been a hot topic for a couple of years, but seems to be heating up again. The discussion has moved on from whether an ABI break should occur at all to whether we can introduce ways to manage it. This proposal does seem like a promising take, but is also quite ambitious in a space that gets a lot of attention! It deals purely with library versioning (in both the standard library and user code) and works best when changes are purely incremental, though it can handle bigger breaks.
The way it works is that you first declare interface tags for the versions you support. These declarations may define superset/subset relations – similar to an inheritance hierarchy – so v2 may include all of v1, for example.
Then you use these tags to scope blocks (of state or functionality) that are specific to a version. Calling code can specify a version to resolve against, or just allow the latest version at compilation time to be used. It can also specify a minimum version in which case a dynamic binding wrapper is generated behind the scenes. That dynamic binding layer adds some overhead, but you only pay for that if and when you need it. Otherwise things are resolved statically (or as static as your interface) and the versions are baked into the object files.
So, the first impression: a promising approach which seems to have considered most concerns. But as it’s quite a significant set of features, with the potential for many unforeseen interactions, I’m sure this is going to get plenty of scrutiny and probably evolution before being accepted, if at all. If we don’t end up getting this, the discussion may inform another approach we can explore, so it’s great that we’re actively trying to break this deadlock with serious proposals.
Building LLVM with Llama
Llama is a tool for running UNIX commands inside of Amazon Lambda. And llamacc is a replacement for gcc and clang to execute the compilation in the cloud. If you use llamacc or llamac++ as your compiler, you can build using make or a similar build system with a much higher -j concurrency than your normal number of cores.
If you use Llama for a full build of clang+LLVM, the build will take about 80 seconds, as explained in this great article. It explains how the compilation process is executed in Amazon Lambda, as well as what could be done to optimize the build speed further. Interestingly, the LLVM build time seems to be affected by the issue in cmake’s Ninja generator, which emits unnecessary dependencies of add_custom_command(). The author also suggests that some really long files in LLVM can be split into several files to benefit from the parallel build. Could building in the cloud win over local builds on powerful machines in the future? Check out the article to decide.
A default value to dereference null pointers
Another short but practical post from Jonathan Boccara in his blog is dedicated to dealing with pointers in the same expressive way as with C++17 std::optional. As you may know, optional provides the value_or member function, which helps us handle optional’s nullity in a nice way. Could we have the same for pointers? Of course, but a free function rather than a member function. The blog post suggests an implementation and talks about inferring the return type of such a function. In the comments, readers discuss how they handle null pointers in their code. What would you add?
Finding bugs with AddressSanitizer
Exploring how tools can be applied to real-world open-source projects is always interesting and inspires broader usage. Microsoft has recently added AddressSanitizer to Visual Studio and published a blog post covering a few cases from the open source world where AddressSanitizer helped catch real-world bugs. In fact, they already caught an issue in the MSVC compiler and wrote about it earlier in April.
In this new blog post they cover three open-source projects:
Boost: the problem was in dereferencing the end iterator.
Azure IoT C SDK: the global buffer overflow happened there due to the incorrect size value passed to memcpy function.
OpenSSL: another memory access bug, now caused by the assumption about the type sizes, which depends on the architecture the program is being compiled for and so might be incorrect.
The team also provides the links to the fixes in the GitHub repositories of the corresponding projects. Read the blog post for more details.
All major Vcpkg enterprise features are no longer experimental
Vcpkg, a C/C++ dependency manager from Microsoft, has made a huge step forward and announced that all core features are no longer experimental. The announcement relates to versioning and registries, combined with manifests and binary caching,which were announced earlier.
In short, these four major features are essential for package management:
Versioning: allows users to rely on specific versions of the libraries.
Registries: allows users to work with their own (even private) libraries via vcpkg.
Manifests: enables the shareable way of maintaining the dependencies automatically (for MSBuild and CMake).
Binary caching: allows reusing the pre-built binary libraries via vcpkg.
These features are not new, so what exactly has changed? It seems that a move from an experiment to a regular feature should guarantee some stability and quality of implementation. As the author of the blog post says, “we are confident enough to recommend using them in production environments.”
Along with the announcement, vcpkg started a new site with the updated branding. Its most interesting feature is the ability to browse the available packages. It searches as you type, showing you the list of matching packages, their versions, platform compatibility, and the vcpkg commands to install them.
CLion starts its 2021.2 Early Access Program
The CLion 2021.2 EAP program has begun! The first build introduces some noteworthy CMake enhancements, like initial support for CMake Presets. CLion can now load the build presets into its own CMake Profiles and use them for CMake generation on projects. The current mode only assumes read-only access in the CLion UI, even though users still can edit the JSON files with presets in the CLion editor and call the Load CMake Presets action again. The CLion team plans to collect the feedback and evolve the experience further after carefully listening to users’ needs and use cases. The first EAP build also bundles CMake v3.20 and brings templates for new CMake projects created in CLion.
To help users address safety issues in their C++ code, CLion 2021.1 EAP implements some of the Lifetime Analysis checks suggested in Herb Sutter’s proposal. The new version also adds support for interactive C++ interpreter, Cling, so you can now start a Cling session right in the IDE and easily send includes directives, lines of code, and whole selections to Cling. Check out other enhancements in the blog post and download the free EAP build to give it a try on your projects.
Conference news
Early Access to C++Now 2021 recordings
Generally regarded as the year’s most academic event in the C++ community, C++Now moved to an online format in 2021 without losing any of its most distinctive qualities. It offered insightful discussions about some of today’s hottest topics, like C++ ABI stability, CMake, C++20 modules and concepts, and more. Together with Bloomberg, JetBrains is proud to support the event as a video sponsor and will bring you early access to this year’s conference recordings!
We will be publishing the talks over the course of several weeks on this page: http://jb.gg/cppnow. After all of the presentations are released, they will be made publicly available on C++Now’s official YouTube channel. But you don’t need to wait for that – you can start watching those that are already live on our web page. Stay tuned for more in the next few weeks!
Meeting C++’s call for papers has started
Meeting C++ 2021 has been announced as a fully online event, happening November 10–12, 2021. As more conference organizers are experimenting with online formats, Jen Wellers, who is hosting the Meeting C++ event, is planning to skip the keynotes this time and think more about other formats for the attendees. It will be interesting to see what he comes up with. Meanwhile, the call for papers is open until June 30.
Full schedule for C++ on Sea is announced
Another online format experiment will run quite soon, in the end of June and beginning of July. C++ on Sea has announced its full schedule. It consists of five tracks of workshops over two days, including half-day, one-day, and two-day workshops, as well as one more “classic” day of regular 60-minute talks. To give you a brief overview, the workshops include concurrency topics by Anthony Williams, a C++20 overview by Nicolai Josuttis, testing legacy code by Clare Macrae, and other interesting topics. I’ll also be giving a half-day workshop dedicated to Code Analysis in modern C++. The days of talks features Victor Ciura, Kevlin Henney, Mateusz Pusz, as well as closing keynotes by Ansel Sermersheim and Barbara Geller.
The early access program for CLion 2021.2 is already open. Meanwhile, we’re working on bug fixes for version 2021.1 and today have released the 2021.1.2 bug-fix update.
Build 211.7442.42 is now available on our website, via the patch-update, in the Toolbox App, or as a snap (for Ubuntu).
Quick fix to change return type or add return statement is available now for consteval functions.
A lot of fixes for false positives in the Unused code inspection, as well as fixes for the corresponding safe delete quick fixes.
Code formatting:
Incorrect reformatting of the bitwise XOR is fixed.
Incorrect braces indentation after #pragma omp parallel is fixed.
Debugger:
GDB 10.1 no longer crashes when printing a struct variable with a flexible array member (CPP-24874).
GDB on macOS now works with remote targets.
Project models:
Custom Build Application configuration now skips the Build step if the tool is not specified (CPP-25004).
Other improvements:
Fixed the problem causing the color scheme to change unexpectedly (IDEA-265169).
Chinese characters are now displayed correctly when the Quick Documentation action is invoked (IDEA-268158).
Tab and indent settings no longer reset when you relaunch the IDE (IDEA-267368).
You can find the full release notes here. If you haven’t yet updated to v2021.1, now is a great time to do so. Check out the 2021.2 EAP if you are interested in what’s coming next.
