CLion 2020.2: Makefile design model support, more C ++ 20 and more

Hello, Habr!



Our team had a very busy summer, the results of which we are in a hurry to share today. So, welcome the new release of CLion 2020.2!







Briefly about what is included in the new version :

• Makefile design model support.
• Latest updates in CMake.
• C++20: explicit(bool), (designated initializers), for .
• : (dangling pointers), , , , .
• -: doctest, Catch2 Google Test. .
• PlatformIO .
• .
• .
• .

Makefile

Having marked the fifth anniversary of CLion this spring , we immediately got involved in the active completion of the most anticipated feature in the IDE - support for projects based on the Makefile. Before that, we only had a crude prototype, which we gave to our most daring users to try privately. Thanks to them, we were able to test the prototype on a wide selection of Makefile projects, fix many problems in it, and understand the current (hopefully temporary) limitations of our solution. Our goal is to allow users to work with a Makefile project in CLion with all the smart IDE features such as navigation, refactorings, static code analysis, and more.



The current approach in short looks like this: CLion runs a command makeon your project with an additional option--just-printto save time on actual assembly. If CLion can successfully parse the command output, then the project opens and everything works!



Let's make a reservation right away that the work on Makefile support in CLion is still far from complete - there are still many known limitations and imperfections. Most notable:

• Projects using libtool ( CPP-19549 ), distcc and ccache ( CPP-19305 ), and other wrappers that "hide" compilation flags from the output or interfere with command output are not supported make.
• CLion is not yet able to handle non-GNU Makes output (e.g. NMake, BSD) ( CPP-18723 ).
• It does not support projects that disable the listing of directory names during the build process, so CLion cannot determine which files are specific to which build commands.

But even the current solution already allows you to open the Linux kernel or PostgreSQL database server code in CLion. If you are interested, then the current list of projects on which our prototype works (as well as some projects where it does not work, with the indicated problems) can be found on this page .



It's very easy to try on your project:

1. Prepare a project in order to get a Makefile for it (for example, in many cases you need to start it ./configure, since CLion itself does not know how to do this yet).
2. Open a project with File | Open and specify the directory that contains the main project Makefile or directly this file itself. Confirm that you want to open as a project.
3. CLion , Clean. , make , .
4. , , ! Build.

The output may contain some warnings, but if the download completed successfully on the whole (there should be a green mark next to the very first task), then you can work with the project in CLion.



Boot command argument settings, the toolchain used for booting, and other options can be found in Settings / Preferences | Build, Execution, Deployment | Makefile:







To run and debug Makefile applications, you will need to create additional Makefile Application configurations. In this case, the target can be selected from the drop-down list - CLion will tell you what options are there:







In our blog in English, you can find more information about working with Makefile projects in CLion. We also recommend watching a short demo (in English):

Latest updates in CMake

As statistics show , the three most popular design models now among C ++ developers are CMake, msbuild and Makefile. And it is CMake that has been leading this rating for three years and continues to grow. Therefore, we are constantly updating the version of CMake that is banned in CLion and are working on supporting the latest innovations in CMake itself. This time we updated the version to 3.17 and accordingly added support for two new useful CMake features:

• Ninja Multi-Config ( Debug Release) Ninja ( -G "Ninja Multi-Config"). CLion , CMake . UI, .
• CMake precompiled headers deserve more attention. In general, the idea of ​​precompiled header files (PCH) is not new and has been supported by compilers for a long time. CLion has also been around with PCH for quite some time. Now you don't have to remember the compiler flags for PCH and pass them to CMake to each specific compiler in your own way, but simply add header files to the PCH target variables via the command target_precompile_headers. CLion 2020.2 is now able to work with this:
  
  
  
  

Also noteworthy is the ability to open a CMake project in CLion from the directory with the result of CMake generation, now not only for the Makefile generator, but for any other! Save time - open already built projects in CLion without restarting the CMake command on the project.

C ++ 20

Did you know that, according to our data , this year already 12% of C ++ developers use the C ++ 20 standard ?! Therefore, we are, of course, actively working to support new features in CLion. But let's first remember what we have with language engines in CLion.



So, at the moment there are two of them - a built-in one based on Java / Kotlin and a fairly new one based on Clangd, respectively, in C ++ (we use CLion to develop it). All efforts are now being put into a Clangd based engine. It seems to be a good prospect, although actions on the entire project (like refactorings) cannot be done on it yet - here even an imperfect and sometimes slow Java-based engine wins due to any specific optimizations and deferred resolutions, and, of course, due to the presence of a cache symbols needed for refactorings.



But Clangd has one very big plus - the whole community is working there to support the latest C ++ standards in Clang, because the project is open. This, of course, does not mean that we do not need to do anything at all - this support still needs to be adapted to the needs of CLion anyway. But this is already easier than writing support for C ++ features from scratch! And on the basis of support in Clang, you can write your own specific analysis or do some special features (for example, we did autocompletion for Concepts a few releases ago).



We made sure that the latest update of the Clangd engine, which came with LLVM, behaves more stable in C ++ 20 code, and in general, according to our built-in statistics, the Clangd engine has become more stable. Therefore, the ability to completely disable the Clangd engine was removed from the settings. But added to Settings / Preferences | Languages ​​& Frameworks | C / C ++ | Clangd information about the revision with which our engine is built. Now you know what to expect from it in terms of support for C ++ and analysis of built-in Clang-Tidy:







By the way, in our online help there is an excellent article with a comparative analysis of the two engines in terms of support for C ++ capabilities.



And now about what actually was added from C ++ 20 support:

• Code completion for C ++ 20 keywords: char8_t, consteval, and constinit, co_await, co_return, and co_yield.
• Completion for fields from the base class in designated initializers:
  
  
  
  
• The construct is explicit(bool)now correctly highlighted, name hints, navigation and refactorings work in it:
  
  
  
  
• For forrange-based loops with initializers, the Rename refactoring for loop variables worked.

Static code analyzer

In the last release, we transferred our most "heavy" analysis - Data Flow Analysis - to a Clangd-based engine. This is mainly to improve performance. But, as often happens, during refactoring, many problems and inaccuracies were found. So in release 2020.2 we continued to improve this analysis and fix bugs in it:

• , , .
• DFA Simplify code Loop condition is never updated. , :
  
  
  
  
  
  
  
  , :
  
  
  
  
  
  
  
  - , . , Clang-Tidy (clang-tidy:bugprone-infinite-loop), - . CLion :
  
  
  
  
• CLion (dangling pointers)! (, ), :
  
  
  
  
• , Concepts C++20, - auto, :
  
  
  
  

In this release, everyone's favorite Inspection Hector (whom some of our users even tried in vain to make fun of ) has turned into a new Inspection Widget located in the upper right corner of the editor area. Now it is there that the options for setting the backlight level are located (from showing all problems to completely disabling the code analyzer), and when you click, a window of static analysis results for this file opens:

Unit testing

The research already mentioned here more than once shows that 34% of C ++ developers do not write any unit tests . I would like to believe that in return they conduct testing in some other way. Part of the problem is that C ++ does not have a standard design model or a standard dependency manager, which means adding a unit testing framework to your project is not easy. But now the so-called header-only frameworks are becoming especially popular, which are easy to connect to your project - add a header file and write yourself tests. For our part, in the IDE we try to support as many options as possible. In this release, doctest has been added to the set from Google Test, Catch, Boost.Test. By the way, we had a guest blog post a while agofrom its author, where Viktor talked about the advantages of this framework.



CLion support includes the usual things:

• Automatic test detection.
• Automatic creation of configurations for running and debugging tests.
• Output of test results in a special built-in window with various filtering and ordering options, as well as with one-click transition to the test source code.
• Icons in the editor, in the left pane, for running tests and identifying the status of the last run of tests.

Google Test and Catch2 support has also been updated:

• Support for template tests has been added for Catch2.
• And for Google Test, support for a macro GTEST_SKIP(), which can be very useful if you want to be able to skip some tests, for example, in specific environments.

A small overview video about improvements in unit testing support from our lawyer (by the way, the author of the Catch / Catch2 framework):





Warning your questions about CTest: making it a little more difficult, because this is not a “regular” framework, but a certain level of abstraction for running anything as a test. But we are planning some integration as early as 2020.3!

And

The most interesting, perhaps, discussed, now briefly about the rest. I should have started with this, but CLion 2020.2 includes many small but important improvements to editor performance and editor hangs fixes. One such improvement, for example, is the insertion of a backslash when pressed Enter inside a macro definition . It would seem like this helps the productivity of the editor? The fact is that most likely the new line is part of the definition of the current macro, and inserting a backslash allows you to avoid unnecessary reparsing of a bunch of code, and hence the brakes of the editor.



Besides:

• PlatformIO — , platformio.ini CMake .
• , IntelliJ . : GitHub Pull Requests Git WSL2 ( WSL2, CLion Git ).
• In terms of debuggers in 2020.2, we managed to do less than planned. Basically, all big tasks have been postponed to 2020.3 (debugging as root, debugging core dumps). But in this version we have upgraded the banned version of GDB to 9.2 and also updated the GDB STL pretty printers. Many improvements, both functional, performance and stability, have been made in our LLDB-based debugger for the Microsoft Visual C ++ toolchain.

That's all for today. Have you read to the end? Thank you very much for your attention! Try it , write questions, suggestions, exclamations in the comments - we are always happy to read and answer them!



CLion Team

The Drive to Develop