CLion2020.2

Version 2020.2:

Makefile projects support:

• Our developer ecosystem study revealed that the top 3 project models for C++ projects are CMake, Visual Studio, and Makefiles. From the very first versions, CLion has treated CMake as a first-class citizen, providing many productivity-boosting features for it. Among other supported project models, in CLion you’ll find Gradle, Compilation Database, and Bazel (via a 3rd-party plugin). This list of supported project models is probably the biggest limitation of CLion. CLion 2020.2 is now open to a wider variety of C and C++ projects due to the introduction of a much-requested feature - support for Makefiles projects!
• To be able to load a Makefile project, CLion runs make on it, by default with the --just-print option to avoid actually building it, and parses the output of the make command. If parsing is successful, CLion loads the project and enables all the smart IDE features for it.
• The arguments of the make command, as well as the Build target and Clean target commands used by CLion to load the project, are configurable in Settings/Preferences | Build, Execution, Deployment | Makefile
• In Run/Debug configurations you can select the Makefile Application configuration, allowing you to run and debug your Makefile targets.
• Support for makefile projects in CLion is still in its early stages with various limitations and known issues. However, we’ve tested it on a long list of projects, which you can find on our Confluence page. We also want to sincerely thank all early previewers who gave this new feature a try and shared their feedback! Feel free to check out this blog post for the implementation details, a few configuration tips, and a list of known issues, as well as our future plans in this direction.

Modern CMake support:

CLion 2020.2 bundles CMake 3.17 and now offers necessary support for a few useful features from the recent CMake updates:

• Ninja Multi-Config is an option (-G "Ninja Multi-Config") for the Ninja generator in CMake that allows you to get build files generated for all configurations at once. While CLion 2020.2 generates them all, it still uses only one, selected in the CMake Profile settings. We are planning to add a UI to support multi-config generators, later (CPP-20890).
• The precompiled headers (PCH) technique can speed up compilation by creating a partially processed version of some header files, and then reusing it during subsequent compilation runs. CMake precompiled headers is a great unification feature, which allows you to organize precompiled headers in your project in a compiler-independent way. You just use the target_precompile_headers command to add header files to the PRECOMPILE_HEADERS and/or INTERFACE_PRECOMPILE_HEADERS properties of a target. You no longer need to remember the multitude of compiler flags for PCH and pass them via the project model! New CMake commands and properties are now supported by CLion, which means code resolve and all IDE features work correctly.
• Note that this doesn’t currently work for Cygwin/WSL/Remote toolchains, but we plan to add it later.
• Imagine the situation when you open a CMake project that has a CMake folder already generated. CLion can open the project without regenerating the folder, which saves a considerable amount of time for some projects. This feature previously worked only for the Makefile generator, but now it is supported for all generators (like Ninja, or others). Give it a try!
• You’ll also find an updated UI in Settings/Preferences | Build, Execution, Deployment | CMake, and a new list of CMake actions in Find Action, which you can now assign a shortcut to for your convenience: CMake Settings, Stop CMake project reload, and Open CMakeCache file.

Better C++20 standard compliance:

This year brings a new C++ standard to developers. In this release, we devoted a lot of effort into improving the C++ language support in CLion. The Clangd-based language engine is generally more stable now with the C++20 code. In addition, a few more specific features have been added:

• Code completion for C++20 keywords: char8_t, consteval and constinit, co_await, co_return, and co_yield.
• For designated initializers, code completion now works for fields from a base class
• Not only is the C++20 explicit(bool) now highlighted correctly, name hints for condition arguments also work there, as do navigation and refactorings
• In range-based for loops with the init statement, refactorings like Rename work for variables in the loop in CLion 2020.2.

Code analysis:

In this release we improved the built-in code analysis in CLion by completely reworking some of the checks and adding a few new ones:

• We added a new inspection for C++20 Concepts. It suggests constraining local variables declared as auto if the result of a constrained function call is assigned to them
• A check has been added to catch dangling pointers. We all know how dangerous cases with double-free and use-after-free can be. With a few limitations, CLion 2020.2 now helps you to detect such cases
• The Simplify code inspection has not only become more accurate, but it’s also now less CPU-consuming. Fine-grained configuration options are now available under Settings/Preferences | Editor | Inspections | C/C++ | General | Simplifiable statement
• The Loop condition is never updated inspection, similarly to Clang-Tidy’s clang-tidy:bugprone-infinite-loop, detects situations where a loop condition is not updated inside the loop. CLion’s inspection works nicely for loops with exit points and can handle cases with lambdas or references.
• The Unused code inspection and Data Flow Analysis in general were both greatly improved in this release.
• CLion 2020.2 also introduces a new Inspection Widget and the Problems tool window to check the list of warnings and errors in the current file

Unit testing:

• What’s your favorite unit testing framework? Do you write unit testing as all? The developer ecosystem study that we carried out in the beginning of 2020 found that 34% of C++ developers don’t write unit tests, while 15% do but don’t use any specific framework. However, among the majority who do run unit tests on their C++ projects, the 5 most popular frameworks were identified as Google Test, Catch, Boost.Test, CppUnit, and Doctest.

CLion has already supported the top 3 frameworks for a long time. Version 2020.2 enhances integration with the newer versions of Google Test and Catch2 by adding support for:

• The GTEST_SKIP() macro in Google Test, to skip tests at runtime
• Catch2 template tests.
• This version also adds Doctest to the list of the frameworks supported in CLion
• This mean that Doctest tests are detected by CLion and Run/Debug configurations are created automatically when you run an individual test or all tests in a file, and the results of the test launches are presented in the built-in test runner, which helps analyze the test results, navigate to the source code, and rerun failed tests or all tests. Learn more about Doctest support in CLion in this dedicated blog post.
• Code coverage is important - when you do unit testing for your code, it’s useful to see how well your code is covered by the tests. You can run your tests with coverage in CLion, and starting from 2020.2 you no longer need to manually create a CMake Profile and specify all the necessary compiler flags in it. If the proper configuration is missing, CLion will now create one based on the CMake profile you are currently using.

Updates to the Go to Declaration or Usages action and Clangd configuration:

• You probably know that CLion handles C and C++ code with the help of two language engines: one is built into CLion, and the other is based on Clangd. The Clangd-based engine is younger but is evolving faster than CLion’s own engine, and incorporates a huge amount of work done by the C++ community to support new language features. Our team implements code highlighting, completion, parameter hints, unique code analysis features (like Data Flow Analysis, and others), some navigation actions, and other features on top of it. You can check out our online documentation for a detailed comparison of the two engines. CLion 20202.2 shows the LLVM Clang revision used for the Clangd-based language engine so that you know what to expect in terms of C++ support and built-in Clang-Tidy checks
• We’ve also applied some effort to making sure the Clangd-based engine is as stable as possible. We are now so confident in it that it has become the default language engine in CLion and the option to turn it off has been removed.
• Another important change is the behavior of the Go to Declaration or Usages action (Ctrl+Click / Ctrl+B on Linux/Windows, ⌘Click / ⌘B / force-touch on macOS). A new setting under Settings/Preferences | Editor | General | Go to Declaration or Usages allows you to specify whether it should show the list of usages or show the associated declaration when the action is invoked on a definition.

Debugger improvements:

• CLion integrates with the GDB and LLDB debuggers, and on Windows it also comes with the JetBrains LLDB-based debugger for the Microsoft Visual Studio toolchain. This debugger is now used in two of our IDEs - CLion and Rider for Unreal Engine. In version 2020.2 it gets lots of improvements: we’ve eliminated freezes on stop and a number of crashes, made general performance improvements, and introduced automatic thread naming, in addition to some other fixes. The debugger is bundled with CLion and is enabled automatically when you select the Microsoft Visual Studio toolchain. Give it a try and let us know what you think!
• CLion 2020.2 updates the bundled GDB STL pretty printers and upgrades the bundled version of GDB to 9.2.

IDE performance:

• We still treat IDE performance as our top priority, and we continue to fix UI freezes and improve CPU and memory consumption. Among many such fixes in this release, one deserves a special mention: in order to avoid editor performance degradation, CLion now inserts a backslash when you press Enter inside a macro definition. The macro definition will quite likely be continued on a new line, so this saves the IDE from redundantly reparsing activity.

Easier embedded development with the updated PlatformIO plugin:

• The PlatformIO plugin in CLion helps you start an embedded project faster. During this iteration we improved it by adding highlighting in platformio.ini files, automatically generating various useful Run/Debug configurations, and creating CMake Profiles for the CMAKE_CONFIGURATION_TYPES entries from the PlatformIO projects. Our next step will most likely be to rework the project model approach (which currently generates CMake for CLion), however we might postpone this until 2021.

VCS support update:

• As usual, the IntelliJ Platform has been updated with many improvements to VCS support. This includes new and richer functionality in the GitHub Pull Requests view. Learn more about this on the IntelliJ IDEA page.
• Our WSL2 users will be happy to learn that Git installed on WSL2 is now automatically detected by the IDE, and all Git-related features automatically switch over to work with it.