CLion Starts 2021.1 EAP: Global DFA, Updated Project View, CMake 3.19

Anastasia Kazakova

We’re launching the CLion 2021.1 Early Access Program!

At the end of 2020 we shared our areas of focus for 2021 and our plans for the 2021.1 release. And today we’re inviting you to join the 2021.1 Early Access Program!

As usual, the EAP builds are free to use and no license is required. The main goal is to test the tools in all kinds of non-standard and unusual environments you may have set up, so we can make sure we haven’t missed anything. If you come across any bugs or peculiar behavior, please report them to our issue tracker so we can collect and fix as many issues and regressions as possible.

DOWNLOAD CLION 2021.1 EAP

Build 211.4961.39 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 MAC, there is a separate build for Apple Silicon (M1 chip).

Here are the main highlights:

• Global DFA mode in code analysis.
• Files outside of the project content root are now grouped under a separate node to avoid top-level pollution.
• Google Sanitizers, Valgrind Memcheck, and Code Coverage are available in Remote mode.
• CMake 3.19 is now bundled.

Global Data Flow Analysis

For a while we’ve been focusing our efforts on CLion’s performance and overall quality improvements. One area we continue to improve on is Data Flow Analysis. In 2020 we partially moved it to the clangd-based engine, increased the accuracy of many checks, and added new checks, like search for dangling pointers. And in CLion 2021.1, we’re ready to give you Global Data Flow Analysis!

Global DFA is an interprocedural analysis that takes the translation unit (TU) of a program as a single unit for analysis. This means global DFA works within the TU on all usages of the functions/fields that are guaranteed to be located in the TU. This helps detect potential issues which can’t be captured by Local DFA. For example, dangling pointer analysis is enriched with Global DFA and can capture cases when memory is deleted in another function:

Here’s a list of CLion’s current DFA-based inspections that benefit from Global DFA:

• Constant conditions – detects possible conditions that are always true or false.
• Unreachable code – detects code that is never executed.
• Null dereference – detects dereferencing pointers that may contain nullptr.
• Dangling pointers – detects pointers that may point to already deleted memory.
• Endless loops – reports any for, while, and do statements or goto loops that can exit only by throwing an exception.
• Infinite recursion – reports functions that either run forever or terminate by an exception.
• Unused values – detects variable values that are never used after being assigned.
• Escape analysis – detects variables containing references to local variables that escape their scope.

In addition to those, we are working on a few new inspections only available in Global DFA:

• Constant function result – reports functions whose return value appears to always be the same constant.
• Constant parameter – reports functions where a parameter appears to always be the same constant:
  
• Unreachable calls of function – detects functions whose call sites are never executed:
  

Global DFA is enabled by default, but it can fall back to Local DFA if:

• There is an error in any of the functions in the TU reported by the clangd engine.
• The file is included in another TU.
• Global DFA is manually turned off via the Registry key clion.dfa.global (which we do not recommend unless a critical regression is found).

Global Data Flow Analysis performance

When implementing such a big change, we were obviously interested in how it would affect the performance of code analysis. And since we were optimizing many steps in DFA, we were expecting some improvements.

We compared the previous and current DFA implementations, running both in global and local mode. Here are the measurements we got from our MAC machine (Big Sur 11.0, 2.6 GHz 6-Core Intel Core i7, 16 GB RAM). For the test, we took 5 projects: Postgres, Eigen, clangd, OpenCV, and OSRM. We measured the performance of each DFA step separately:

1. Building relations step – this is the C++ implementation of the engine that collects all the relations for the DFA calculation. As we began collecting more data, we expected the times would grow:
   
2. Running relations manipulation step – at this step the relations are processed and the output relations are produced, which after the interpretations become the actual inspections that CLion’s editor shows you. This accounts for most of the analysis time, and we managed to improve the performance here thanks to various optimizations:
   
3. The number of files where DFA execution was terminated by CLion because of a timeout (the default timeout is 5 seconds). We see an improvement here as well:
   

Looks like the performance isn’t too bad after all.

Give the new global DFA a try in CLion 2021.1 EAP and let us know how it works for you. If you experience any issues with DFA in CLion and in particular the new Global DFA mode, please file a bug report in our tracker. Some known issues on Global DFA that we are aware of are linked to CPP-23192.

Project sources from the outside of the project root

Any project in CLion is considered encapsulated within the project directory – a root directory referred to as a project root directory that contains all the project files and subdirectories. It’s usually a top-level directory where the main CMakeLists.txt or Makefile is located, but users can also change this directory explicitly via the Change Project Root action.

Now if the project uses some source files located outside of the project root, you will see them grouped under the External Sources node in the Project tree:

This helps avoid top-level crowding which would often happen previously, for example when generating project files required for code assistance and compilation.

Dynamic Analysis in Remote mode

As one of our major goals for 2021 we’re pursuing feature consistency across all toolchains, project models, and configurations. One small step we’ve made in this direction is that Google Sanitizers, Valgrind Memcheck, and Code Coverage now also work with remote toolchains in CLion.

CLion bundles CMake 3.19

CLion now supports and bundles CMake 3.19.2. This is the first CMake version to support Apple Silicon (M1 chip). Remember that starting with v2020.3.1, CLion runs natively on Apple Silicon (make sure to use the correct separate installer for this though).

In addition, new CMake features for CUDA are now supported in CLion, CLion can now autocomplete a few new CMake variables, and there are some other updates we’ve verified to work correctly with CLion.

Please note that CMake presets (CPP-22906) and ISPC language (CPP-23363), which were also added in CMake 3.19, do not have any specific support in CLion for now.

The full release notes are available here. There are more than 100 fixes included, so make sure to try out the new EAP build today!

DOWNLOAD CLION 2021.1 EAP

Your CLion team
JetBrains
The Drive to Develop

Subscribe to CLion Blog updates

Subscribe form

By submitting this form, I agree to the JetBrains Privacy Policy Notification icon

By submitting this form, I agree that JetBrains s.r.o. ("JetBrains") may use my name, email address, and location data to send me newsletters, including commercial communications, and to process my personal data for this purpose. I agree that JetBrains may process said data using third-party services for this purpose in accordance with the JetBrains Privacy Policy. I understand that I can revoke this consent at any time in my profile. In addition, an unsubscribe link is included in each email.

Submit

Thanks, we've got you!