CLion 2020.2: поддержка проектной модели Makefile, больше C++20 и не только

Oksana Mandryka

У нашей команды выдалось очень насыщенное лето, результатами которого мы и спешим сегодня поделиться. Итак, встречайте новый релиз CLion 2020.2!

Коротко о том, что вошло в новую версию:

• Поддержка проектной модели Makefile.
• Последние обновления в CMake.
• Новые возможности C++20: explicit(bool), назначенные инициализаторы (designated initializers), циклы for на основе диапазонов с инициализаторами.
• Обновленный статический анализатор кода: анализ на висячие указатели (dangling pointers), поиск возможностей упрощения кода, поиск неиспользуемого кода, анализ возвращаемого значения функции, ограниченной концептом.
• Юнит-тестирование: поддержка нового фреймворка doctest, новые возможности Catch2 и Google Test. А также упрощение сбора метрик покрытия кода.
• Обновления в плагине PlatformIO для разработки встроенных систем.
• Улучшения в поддержке систем контроля версий.
• Улучшения производительности редактора.
• Исправления в отладчиках.

Поддержка проектной модели Makefile

Отметив этой весной пятилетие CLion, мы тут же включились в активную доработку самой ожидаемой возможности в IDE — поддержки проектов на основе Makefile. До этого у нас был только сырой прототип, который мы давали попробовать в частном порядке самым смелым нашим пользователям. Благодаря им мы смогли проверить прототип на широкой выборке Makefile-проектов, исправить множество проблем в нем и понять текущие (надеемся, временные) ограничения нашего решения. Наша цель — позволить пользователям работать с проектом на основе Makefile в CLion со всеми умными возможностями IDE, такими как навигация, рефакторинги, статический анализ кода и другие.

Текущий подход вкратце выглядит так: CLion запускает команду make на вашем проекте с дополнительной опцией --just-print, чтобы сэкономить время на реальной сборке. Если CLion может успешно распарсить вывод команды, то проект открывается и все работает!

Сразу оговоримся, работа над поддержкой Makefile в CLion еще далека от завершения — известных ограничений и недоделок еще много. Самое заметное:

• Не поддерживаются проекты, использующие libtool (CPP-19549), distcc и ccache (CPP-19305), и другие обертки, которые “скрывают” флаги компиляции из выдачи или вмешиваются в вывод команды make.
• CLion пока не умеет работать с выводом non-GNU Makes (например, NMake, BSD) (CPP-18723).
• Не поддерживаются проекты, которые отключают вывод имен директорий в процессе сборки, так что CLion не может определить, к каким именно файлам относятся те или иные команды сборки.

Но даже текущее решение уже позволяет открыть в CLion ядро Линукса или код сервера базы данных PostgreSQL. Если интересно, то текущий список проектов, на которых наш прототип работает (а так же некоторые проекты, где он не работает, с указанными проблемами) можно найти на этой странице.

Попробовать на своем проекте очень просто:

1. Подготовить проект, чтобы получить Makefile для него (например, во многих случаях надо запустить ./configure, так как CLion пока что сам не умеет этого делать).
2. Открыть проект через File | Open и указать директорию, которая содержит самый главный проектный Makefile или прямо сам этот файл. Подтвердить, что открыть хотите как проект.
3. CLion уточнит, запустить ли Clean. Это нужно, чтобы вызов команды make подхватил все файлы, а не только последние изменения.
4. Это, собственно, и все! Результат попытки загрузки проекта будет выведен в окно Build.

Вывод может содержать какие-то предупреждения, но если загрузка завершилась в целом успешно (около самой первой задачи должна быть зеленая отметка), то с проектом можно работать в CLion.

Настройки аргументов команды загрузки, тулчейн, используемый для загрузки, и другие опции можно найти в Settings/Preferences | Build, Execution, Deployment | Makefile:

Для запуска и отладки Makefile-приложений потребуется дополнительно создать конфигурации Makefile Application. При этом таргет можно будет выбрать из выпадающего списка — CLion подскажет, какие есть варианты:

В нашем блоге на английском языке можно найти больше информации о работе с проектами на Makefile в CLion. Также рекомендуем к просмотру короткое демо (на английском):

Последние обновления в CMake

Как показывает статистика, три самых популярных сейчас проектных модели среди разработчиков на C++, это CMake, msbuild и Makefile. И именно CMake возглавляет этот рейтинг уже три года и продолжает расти. Поэтому мы непрерывно обновляем забандленную в CLion версию CMake и работаем над поддержкой последних нововведений в самом CMake. В этот раз мы обновили версию до 3.17 и соответственно добавили поддержку двух новых полезных возможностей CMake:

• С Ninja Multi-Config теперь возможно генерировать все конфигурации (а не только выбранную Debug или Release) при использовании Ninja генератора (включается через -G "Ninja Multi-Config"). CLion правда пока использует только одну конфигурацию, указанную в настройках профиля CMake для проекта. Но это ограничение текущего UI, которое мы планируем исправить в будущем.
• CMake precompiled headers заслуживают большего внимания. Вообще, идея предкомпилированных заголовочных файлов (PCH) не нова и поддерживается компиляторами уже давно. CLion также умеет работать с PCH довольно давно. Теперь же можно не вспоминать флаги компилятора для PCH и не передавать их в CMake каждому конкретному компилятору по-своему, а просто добавить заголовочные файлы в PCH-переменные таргета через команду target_precompile_headers. CLion 2020.2 теперь умеет с таким работать:

  

Заслуживает внимания и возможность открыть CMake проект в CLion из директории с результатом генерации CMake, теперь не только для генератора Makefile, но и для любого другого! Экономьте время — открывайте уже собранные проекты в CLion без перезапуска команды CMake на проекте.

С++20

А вы знаете, что, по нашим данным, в этом году уже 12% разработчиков на C++ используют стандарт C++20?! Поэтому мы, конечно, работаем активно над поддержкой новых возможностей в CLion. Но давайте сначала вспомним, что у нас вообще с языковым движками в CLion.

Итак, на текущий момент их два — встроенный на основе Java/Kotlin и довольно новый на основе Clangd, соответственно на С++ (для его разработки мы пользуемся CLion). Сейчас все усилия вкладываются в движок на основе Clangd. Он кажется хорошей перспективой, хотя действия на всем проекте (вроде рефакторингов) на нем пока делать нельзя — тут даже не идеальный и местами медленный Java-based движок выигрывает за счет всяких специфических оптимизаций и отложенных резолвов, ну и, конечно, за счет наличия кэша символов, необходимого для рефакторингов.

Но у Clangd есть один очень большой плюс — над поддержкой последних стандартов C++ в Clang там работает все сообщество, ведь проект открытый. Это, конечно, не означает, что нам совсем ничего не надо делать — эту поддержку все равно потом надо адаптировать под нужды CLion. Но это уже проще, чем писать поддержку возможностей C++ с нуля! А еще на основе поддержки в Clang можно писать свой специфический анализ или делать какие-то специальные фичи (так мы, например, сделали автодополнение для Concept-ов несколько релизов назад).

Мы убедились, что последнее обновление Clangd-движка, пришедшее с LLVM, стабильнее ведет себя на коде на C++20, да и в целом по нашей встроенной статистике Clangd-движок стал стабильнее. Поэтому убрали из настроек возможность полностью отключать Clangd-движок. Зато добавили в Settings/Preferences | Languages & Frameworks | C/C++ | Clangd информацию о той ревизии, с которой собран наш движок. Теперь вы знаете, чего ожидать от него в плане поддержки C++ и анализа встроенного Clang-Tidy:

Кстати, в нашем онлайн-хелпе есть отличная статья со сравнительным анализом двух движков в плане поддержки возможностей C++.

А теперь о том, что же собственно добавилось из поддержки C++20:

• Автодополнение для ключевых слов C++20: char8_t, consteval и constinit, co_await, co_return, и co_yield.
• Автодополнение для полей из базового класса в назначенных инициализаторах:

  

• Конструкция explicit(bool) теперь правильно подсвечивается, в ней работают подсказки имен, навигация и рефакторинги:

  

• Для циклов for на основе диапазонов с инициализаторами заработал рефакторинг Rename для переменных цикла.

Статический анализатор кода

В прошлом релизе мы перевели самый “тяжелый” наш анализ — анализ потока данных (Data Flow Analysis) — на движок на базе Clangd. Это сделано в основном для улучшения производительности. Но, как часто бывает, при рефакторинге было найдено много проблем и неаккуратностей. Так что мы в релизе 2020.2 продолжили улучшать этот анализ и исправлять баги в нем:

• Заметнее всего, наверное, был улучшен анализ на неиспользуемый код.
• На DFA также переехали такие вещи как Simplify code и Loop condition is never updated. Для первого в настройках теперь можно настраивать отдельно разные случаи, которые он умеет находить:

  

  К тому же, он теперь более аккуратно работает в случае макросов и шаблонов:

  

  Второй же анализ позволяет находить потенциально бесконечные циклы из-за того, что условие цикла не обновляется внутри цикла. Знатоки могли бы заметить, что аналогичный анализ есть и в Clang-Tidy (clang-tidy:bugprone-infinite-loop), но там он не работает для циклов с точками выхода и зачастую ложно-срабатывает для лямбд и референсов. В CLion анализ работает в данных случаях аккуратно:

  

• В CLion появился анализ на висячие указатели (dangling pointers)! Несмотря на некоторые ограничения (например, он работает только в локальном скоупе), он все равно очень полезен:

  

• Для кода, использующего Concepts из C++20, появился анализ и квик-фикс на добавление концепта к объявлению переменной типа auto, в которую присваивают результат выдачи ограниченной концептом функции:

  

Окно результатов статического анализа

В этом релизе всеми любимый инспектор Гектор (которого некоторые наши пользователи даже тщетно пытались рассмешить) превратился в новый Inspection Widget, расположенный в правом верхнем углу области редактора. Теперь именно там находятся опции настройки уровня подсветки (от показа всех проблем до полного отключения анализатора кода), а при клике открывается окно результатов статического анализа для данного файла:

Юнит-тестирование

Уже упомянутое здесь не раз исследование показывает, что 34% разработчиков на С++ не пишет никаких юнит-тестов. Хочется верить, что взамен они ведут тестирование какими-то другими способами. Отчасти, проблема в том, что в C++ нет ни стандартной проектной модели, ни стандартного менеджера зависимостей, а значит добавить фреймворк для юнит-тестирования в свой проект ох как не просто. Но сейчас становятся особо популярны так называемые header-only фреймворки, которые подключить в свой проект легко — добавил заголовочный файл и пиши себе тесты. А мы со своей стороны в IDE стараемся поддержать как можно больше опций. В этом релизе к набору из Google Test, Catch, Boost.Test еще добавили doctest. У нас, кстати, некоторое время назад был гостевой блог пост от его автора, где Viktor рассказывал, в чем преимущества данного фреймворка.

Поддержка в CLion включает обычные вещи:

• Автоматическое определение тестов.
• Автоматическое создание конфигураций для запуска и отладки тестов.
• Вывод результатов теста в специальное встроенное окно с разнообразными возможностями фильтрации и упорядочивания, а также с переходом к исходному коду теста в один клик.
• Иконки в редакторе, в левой полосе, для запуска тестов и идентификации статуса последнего запуска тестов.

Поддержка Google Test и Catch2 также обновилась:

• Для Catch2 появилась поддержка шаблонных тестов.
• А для Google Test поддержка макроса GTEST_SKIP(), который может быть очень полезен, если хочется уметь пропускать какие-то тесты, например в специфических окружениях.

Небольшое обзорное видео про улучшения в поддержке юнит тестирования от нашего адвоката (кстати, автора фреймворка Catch/Catch2):

Предупреждая ваши вопросы про CTest: сделать его чуть сложнее, потому что это не “очередной” фреймворк, а некоторый уровень абстракции для запуска чего угодно в виде теста. Но мы планируем некоторую интеграцию уже в 2020.3!

А также

Самое интересно, пожалуй, обсудили, теперь коротко обо всем остальном. Надо было с этого начать, но CLion 2020.2 включает множество небольших, но важных улучшений производительности редактора и исправлений подвисаний редактора. Одно из таких улучшений, например, это вставка обратного слэша при нажатии Enter внутри определения макроса. Казалось бы, как это помогает производительности редактора? Дело в том, что скорее всего новая строка — это часть определения текущего макроса, а вставка обратного слэша позволяет избежать ненужного репарсинга кучи кода, а значит и тормозов редактора.

Помимо этого:

• Для разработчиков встроенных систем добавилось несколько важных интеграционных изменений в плагине для PlatformIO — генерация большего количества конфигураций запуска и отладки, подсветка в конфигурационных platformio.ini файлах и создание необходимых проекту профилей CMake автоматически.
• Как обычно, из платформы IntelliJ приехало много улучшений в поддержке систем контроля версий. Из значимого: расширенные возможности по работе с GitHub Pull Requests и поддержка Git на WSL2 (то есть при работе с проектами на WSL2, CLion умеет теперь использовать Git оттуда).
• По отладчикам в 2020.2 удалось сделать меньше, чем планировали. В основном, все большие задачи отодвинуты на 2020.3 (отладка от имени root-пользователя, отладка core-дампов). Но в этой версии мы проапгрейдили забандленную версию GDB до 9.2, а также обновили GDB STL pretty printers. Множество улучшений, как функциональных, так и по производительности и стабильности, было сделано в нашем отладчике на базе LLDB для тулчейна Microsoft Visual C++.

На этом на сегодня все. Дочитали до конца? Спасибо вам огромное за внимание! Пробуйте, пишите вопросы, предложения, восклицания в комментариях — мы всегда с радостью их читаем и отвечаем!

Ваша команда CLion
The Drive to Develop

Оригинал статьи опубликован на habr.com: https://habr.com/ru/company/JetBrains/blog/513304/

CLion 2020.2: Makefile Projects, C++20, Enhanced Code analysis, Doctest, and Other Unit Testing Support Improvements

Anastasia Kazakova

Good news everyone – we’ve released CLion 2020.2!

With this version we make CLion available for a greater variety of C and C++ projects by adding long-awaited Makefile projects support. We’ve continued adding support for the new C++20 standard, which is expected to be officially published this year. We’ve also addressed many typical C++ code issues with new and improved code analysis checks, and we’ve significantly enhanced unit testing framework integration and code coverage workflow.

To update to this version, you can use the Toolbox App, a snap package (on Ubuntu), download the installer from our website, or apply the patch update to upgrade from the last 2020.1 build.

DOWNLOAD CLION 2020.2

Here is a quick overview of the main highlights. If you are interested in the specific details, please read on:

• Makefile projects support
• Modern CMake support
• Better C++20 standard compliance
• Catching more tricky cases with the enhanced built-in code analysis
• More options in unit testing – Doctest and support for new Catch2 and Google Test features
• Updates to the Go to Declaration or Usages action and Clangd configuration
• Debugger improvements
• IDE performance
• Easier embedded development with the updated PlatformIO plugin
• VCS support update

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. We also encourage you to watch this short demo from Phil Nash to see Makefile projects support in action:

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
• CMake precompiled headers.

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.

Phil Nash produced a short video on CMake enhancements in CLion 2020.2:

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:
  
  Note the limitation: this inspection is not supported for function templates with a requires clause constraining the return type.
• 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:

Here’s a video from Phil Nash on the C++20 and code analysis improvements:

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.

Phil Nash produced a short video on unit testing enhancements in CLion 2020.2:

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. If you’d like to learn more about it, check out this blog post.

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.

That’s it for this release, please give CLion 2020.2 a try. Update today if you have an active subscription, or start your free 30-day trial to evaluate the new features!

DOWNLOAD CLION 2020.2

Your CLion team
JetBrains
The Drive to Develop