CLion 2019.3 уже здесь! Повышенное быстродействие редактора и самые долгожданные новые возможности

Привет, Хабр! Многие уже начинают готовиться к новогодним праздникам, закупать подарки, кто-то планирует путешествия на длинные новогодние выходные. А у нас в JetBrains пока еще горячая пора выпуска релизов продуктов. Cегодня я спешу поделиться с вами новостями о недавно вышедшем релизе нашей кроссплатформенной среды разработки для C и C++ — CLion 2019.3.

Мы решили сфокусироваться на проблемах, которые давно беспокоят наших пользователей, — в первую очередь, производительность и отзывчивость редактора, а во вторую — баги, недоделки и очень востребованные, но отсутствующие возможности. Основной целью этого релиза было, как бы пафосно это ни прозвучало, качество.

Для начала, коротко о самом главном в этом релизе:

• Улучшения быстродействия и отзывчивости редактора, в первую очередь автодополнение, реализованное в нашем движке на базе Clangd.
• Ninja-генератор в CMake, настройки CMake по умолчанию и другие улучшения проектной модели.
• Обновления в интеграции с отладчиками.
• Новое действие для переключения между заголовочными и сорс-файлами.
• Более точный анализ кода: новая проверка для виртуальных функций, а также проверка правописания в CMake и в комментариях Doxygen.
• Поддержка концептов из стандарта C++20.
• Метрики покрытия кода.
• WSL2, правила форматирования и именования от Microsoft, обновления VCS поддержки и многое другое.

Ниже поговорим подробнее, но если вы готовы попробовать уже сейчас, то заходите и скачивайте билд с нашего сайта. Как обычно, доступна бесплатная пробная версия на 30 дней.

Быстродействие редактора

Судя по статистике, которую соглашаются нам присылать многие наши пользователи, самое часто используемое действие в CLion — это автодополнение. Именно на нем мы решили сосредоточить внимание в этом релизе, чтобы сделать его более отзывчивым. Для этого мы добавили к уже имеющимся в IDE «поставщикам» автодополнения еще один, на базе Clangd. Суть в том, что все поставщики работают параллельно, и, как только готовы первые результаты, CLion показывает раскрывающийся список вариантов, продолжая по мере надобности подгружать остальные варианты.

Замеры показали, что на простых проектах скорость собственного поставщика CLion и поставщика на основе Clangd отличаются не сильно. Конечно, мы захотели понять, дает ли преимущества такой гибридный подход. Судите сами: А вот на сложных проектах, таких как LLVM, Qt, Boost, Eigen, первые сто результатов от Clangd появляются существенно быстрее.

Подробнее о замерах — в отдельной статье в англоязычном блоге CLion.

Оно достигнуто за счет параллелизации многих процессов на старте, реорганизации классов, загружаемых на старте, оптимизации загрузки шрифтов на macOS. Среди других значимых улучшений стоит отметить платформенное ускорение времени запуска IDE. Конкретные числа для ускорения зависят от настроек окружения, машины, платформы и других факторов.

Мы стараемся сгруппировать их по исходной проблеме и исправлять одну проблему за другой. В CLion, к нашему большому сожалению, до сих пор встречаются подвисания пользовательского интерфейса. Подвисания пользовательского интерфейса остаются самой актуальной для нас проблемой, так что эту работу мы обязательно продолжим и в следующих релизах. Так, в этом релизе мы исправили подвисания в случаях открытого окна использований (Usages View), при переходе на декларацию, при переименовании директивы #include, при использовании «хлебных крошек» и safe delete, а также в других случаях.

Этот рефакторинг умеет переименовывать не только использования имени в коде, но и в строковых литералах и комментариях. Ну и, наконец, ускорения рефакторинга Rename. Это приводило к большим задержкам при поиске популярного имени. Но не всегда это нужно, а поиск имени раньше осуществлялся до того, как пользователь IDE укажет, какие именно использования хотелось бы переименовать. Для этого в настройках Settings/Preferences | Editor | General | Refactorings надо отключить “Enable in-place mode”. Теперь же можно сначала выбрать поиск только по коду, а уже потом запустить сам поиск. В этом случае при вызове рефакторинга (Shift+F6 по дефолту на Windows/Linux, ⇧F6 на macOS), CLion сначала сразу откроет диалог Rename, в котором можно указать параметры поиска:

Улучшения проектной модели CMake

Тут многие из вас наверняка ждали анонс поддержки Makefiles. Но пока что доступен только полуавтоматический подход к их интеграции через compilation database. Более нативная поддержка по-прежнему в разработке, но в этом релизном цикле мы сильно продвинулись вперед и имеем все шансы показать новую поддержку к следующему релизу 2020.1, где-то в конце марта 2020 года.

Раньше мы использовали Makefiles и похожие на него генераторы, так как парсили результирующие файлы (если точнее, это были -G “CodeBlocks – Unix Makefiles”, а на Windows -G "CodeBlocks – MinGW Makefiles" и -G "CodeBlocks – NMake Makefiles"). Зато мы сделали самую долгожданную возможность в поддержке CMake — возможность указать любой генератор CMake, в том числе столь ожидаемый пользователями генератор Ninja! Теперь можно указать любой генератор в профиле CMake в CLion:

15 и выше, так как реализовано через CMake File API, и работает на всех платформах, в удаленном режиме, для WSL/WSL2. Это возможно только при использовании CMake версии 3.

п.), но CLion для индексирования и сборки будет использовать только тот тип сборки, который указан в профиле CMake. Замечу, что такие генераторы как Xcode и Visual Studio являются мульти-генераторами, то есть генерируют файлы для всех типов сборок (Debug, Release и т.

Это значит, что для всех новых проектов в CLion вы можете использовать одни заранее заданные настройки, такие как генератор CMake или директория для генерации CMake. В этом релизе также появились настройки CMake по умолчанию. Настройки можно указать в File | Other Settings | Settings for New Projects…

Это может быть полезно, если у вас настроено несколько удаленных конфигураций, которые на данный момент недоступны, но хочется перезагрузить хотя бы локальные конфигурации. Из важных улучшений проектной модели CMake еще стоит указать возможность перезагружать валидные конфигурации, даже если в проекте присутствуют другие невалидные.

Обновление интеграции с отладчиками

В отладчиках мы решили починить те проблемы и недоделки, которые беспокоят наших пользователей больше всего. Во-первых, CLion теперь читает .gdbinit/.lldbinit из директории проекта. Это полезно, если хочется какие-то настройки отладчика кастомизировать или добавить pretty printers, но только для конкретного проекта. Ранее приходилось эти настройки указывать в конфигурационных файлах отладчика в пользовательской директории. Теперь можно настраивать эти параметры специфично для проекта. Но, чтобы это заработало, надо разрешить такое поведение в самом отладчике в настройках на уровне пользовательской директории (читайте, как это сделать для GDB и как для LLDB).

В новом релизе мы проадейтили встроенный LLDB до версии 9. Интеграция с LLDB доступна на Linux и macOS. Благодаря этому существенно улучшилось представление стандартных контейнеров на обеих платформах. 0, а заодно глобально пересмотрели все встроенные pretty printers. Стоит отметить, что на платформе macOS, библиотека libc++ обрабатывается гораздо лучше, чем libstdcxx. Подробные сравнительные таблички можно посмотреть в нашем англоязычном блоге. Это вроде бы соответствует популярности данных библиотек на этой платформе, но если вы используете libstdcxx на macOS, пожалуйста, расскажите в комментариях поподробнее о таких случаях.

От полностью удаленного варианта, когда и сборка, и отладка проекта происходят на удаленной машине, до вариантов, когда удаленно происходит только отладка проекта. В CLion сейчас существует несколько вариантов удаленной работы с проектом и отладки. В отличие от имеющейся уже давно GDB Remote Debug (да, с названиями у нас не задалось, согласны), в новой конфигурации CLion сам собирает проект (возможно, при этом вам надо настроить параметры кросс-компиляции), загружает исполняемый файл на удаленную машину и запускает вашу программу под указанным gdbserver. Вот именно для второго случая мы добавили еще одну конфигурацию в CLion — Remote GDB Server. Или если невозможна кросс-компиляция. Старая конфигурация больше теперь подходит для сложных вариантов, когда код на одной машине, сборка на второй, а отладка на третьей.

Go to Header/Source files

Да, это случилось! Мы наконец добавили отдельное действие для переключения между заголовочными и сорс-файлами. В чем же главное отличие от старого платформенного Go to Related Symbol? Дело в том, что, будучи общим платформенным действием, Go to Related Symbol старается быть очень точным и подобрать один самый верный вариант. Это и долго, и не всегда правильно в случае C++. Новое действие Go to Header/Source ведет себя иначе:

• Если за 500 мс не находится один единственно верный вариант, то появляется выпадающий список подходящих вариантов, из которых пользователь может выбрать наиболее подходящий.
• Если пользователь уже переходил из этого файла, то файл, куда он переходил, будет вверху списка.
• Дальше в списке будут файлы из этой же директории с совпадающим именем.
• И затем уже будут идти результаты поиска по сопоставлению деклараций и дефиниций.

Стоит отметить особенность поиска (так как с ней уже встречались наши пользователи) — поиск сейчас ведется по непосредственно включенным/включающим файлам. Это временное ограничение, которое необходимо, чтобы не путать символы с одинаковыми именами из разных таргетов.

Анализ кода

В анализаторе кода в CLion появилась новая проверка. Она отлавливает ситуации, когда виртуальные функции вызываются из конструкторов или деструкторов. Почему это плохо, уже много где обсуждалось. Теперь и CLion предупреждает о таких случаях:

Все мы делаем ошибки в правописании, а потом нашим коллегам тяжело читать код и комментарии. Spell Checker — неотъемлемый компонент интегрированной среды разработки. В этом релизе мы включили проверку правописания в файлах CMake и комментариях документации формата Doxygen: Поэтому хорошо, когда IDE подсвечивает такие ошибки.

Меньше ошибок правописания — более читаемый код!

Концепты из C++20

Наша команда вкладывает сейчас большие усилия в языковой движок на основе Clangd. А мировое сообщество C++ активно развивает Clang. В этом релизе мы объединили усилия — взяли экспериментальную ветку Clang с поддержкой концептов из C++20, которую развивает Saar Raz, и влили ее в нашу ветку Clangd. Таким образом, мы получили подсветку кода с концептами и базовые проверки анализатора Clang в CLion:

И в нашем движке на базе Clangd мы реализовали некоторые полезные случаи автодополнения, проверку на использование концепта, рефакторинг Rename для концептов, действия навигации и поиска Go to Definition и Find Usages. Но на этом мы не остановились.

Автодополнение для параметров шаблона, на которые наложены ограничения:

Автодополнение для std::is_same<Other, T> and same_as<T, U>:

Более подробно про нашу совместную работу над концептами можно почитать в англоязычном блоге. Там же есть видео-запись доклада с CppCon 2019, в котором Saar Raz презентовал свою реализацию концептов в Clang и нашу совместную работу по поддержке концептов в CLion.

Метрики покрытия кода

Code coverage — возможность, которую очень ждали и просили пользователи CLion. В прошлом релизе работу в этом направлении начала команда AppCode, а в этом мы подхватили ее для случаев кросс-платформенного C++ уже в CLion.

При этом можно запускать как юнит-тесты, так и обычные конфигурации, и по их исполнению будет подсчитываться частота исполнения тех или иных строк кода. Работают метрики покрытия кода в CLion через интеграцию с инструментами llvm-cov/gcov. Результаты по нескольким запускам можно при желании суммировать в один общий.

Непосредственно результаты можно увидеть либо в специальном окне Coverage:

…либо в левом гаттере в редакторе.

Ну, и самое главное: чтобы это все заработало, требуется передать специальные параметры компиляции:

• Для GCC: -fprofile-arcs -ftest-coverage или --coverage.
• Для Clang: либо такие же флаги, как в случае с GCC, либо -fprofile-instr-generate -fcoverage-mapping. Отличия будут лишь в способе сборки метрик покрытия.

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

Более подробно про опции компиляции и про отображение метрик в CLion можно почитать в нашем онлайн-хелпе.

Другие улучшения

Среди других важных улучшений в этом релизе:

• Поддержка подсистемы WSL2. Настройки в CLion у нее такие же, как у WSL первой версии.
• Поддержка правил форматирования и именования от Microsoft. Данный стиль доступен наравне с Google, LLVM, Qt, GNU, Stroustrup и другими в Settings/Preferences | Editor | Code Style | C/C++.
• Обновления плагина IntelliJ Rust (этим изменениям посвящен детальный пост в нашем англоязычном блоге).
• Обновления поддержки VCS, пользовательского интерфейса и другие изменения из платформы IntelliJ.

Демо

В заключение, традиционный ролик о новых возможностях CLion 2019.3 (на английском):

Наверняка у вас есть вопросы, пожелания, баг-репорты и просто мысли — ждем их в комментариях! Спасибо, что дочитали до конца! Как всегда, с удовольствием ответим и обсудим ваши идеи.

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