Привет, Хабр! Многие уже начинают готовиться к новогодним праздникам, закупать подарки, кто-то планирует путешествия на длинные новогодние выходные. А у нас в JetBrains пока еще горячая пора выпуска релизов продуктов. Cегодня я спешу поделиться с вами новостями о недавно вышедшем релизе нашей кроссплатформенной среды разработки для C и C++ — CLion 2019.3.
Основной целью этого релиза было, как бы пафосно это ни прозвучало, качество. Мы решили сфокусироваться на проблемах, которые давно беспокоят наших пользователей, — в первую очередь, производительность и отзывчивость редактора, а во вторую — баги, недоделки и очень востребованные, но отсутствующие возможности.
Для начала, коротко о самом главном в этом релизе:
Ниже поговорим подробнее, но если вы готовы попробовать уже сейчас, то заходите и скачивайте билд с нашего сайта. Как обычно, доступна бесплатная пробная версия на 30 дней.
Судя по статистике, которую соглашаются нам присылать многие наши пользователи, самое часто используемое действие в CLion — это автодополнение. Именно на нем мы решили сосредоточить внимание в этом релизе, чтобы сделать его более отзывчивым. Для этого мы добавили к уже имеющимся в IDE «поставщикам» автодополнения еще один, на базе Clangd. Суть в том, что все поставщики работают параллельно, и, как только готовы первые результаты, CLion показывает раскрывающийся список вариантов, продолжая по мере надобности подгружать остальные варианты.
Конечно, мы захотели понять, дает ли преимущества такой гибридный подход. Замеры показали, что на простых проектах скорость собственного поставщика CLion и поставщика на основе Clangd отличаются не сильно. А вот на сложных проектах, таких как LLVM, Qt, Boost, Eigen, первые сто результатов от Clangd появляются существенно быстрее. Судите сами:
Подробнее о замерах — в отдельной статье в англоязычном блоге CLion.
Среди других значимых улучшений стоит отметить платформенное ускорение времени запуска IDE. Оно достигнуто за счет параллелизации многих процессов на старте, реорганизации классов, загружаемых на старте, оптимизации загрузки шрифтов на macOS. Конкретные числа для ускорения зависят от настроек окружения, машины, платформы и других факторов.
В 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, в котором можно указать параметры поиска:
Тут многие из вас наверняка ждали анонс поддержки Makefiles. Но пока что доступен только полуавтоматический подход к их интеграции через compilation database. Более нативная поддержка по-прежнему в разработке, но в этом релизном цикле мы сильно продвинулись вперед и имеем все шансы показать новую поддержку к следующему релизу 2020.1, где-то в конце марта 2020 года.
Зато мы сделали самую долгожданную возможность в поддержке CMake — возможность указать любой генератор CMake, в том числе столь ожидаемый пользователями генератор Ninja! Раньше мы использовали Makefiles и похожие на него генераторы, так как парсили результирующие файлы (если точнее, это были -G “CodeBlocks – Unix Makefiles”, а на Windows -G "CodeBlocks – MinGW Makefiles" и -G "CodeBlocks – NMake Makefiles"). Теперь можно указать любой генератор в профиле CMake в CLion:
Это возможно только при использовании CMake версии 3.15 и выше, так как реализовано через CMake File API, и работает на всех платформах, в удаленном режиме, для WSL/WSL2.
Замечу, что такие генераторы как Xcode и Visual Studio являются мульти-генераторами, то есть генерируют файлы для всех типов сборок (Debug, Release и т. п.), но CLion для индексирования и сборки будет использовать только тот тип сборки, который указан в профиле CMake.
В этом релизе также появились настройки CMake по умолчанию. Это значит, что для всех новых проектов в CLion вы можете использовать одни заранее заданные настройки, такие как генератор CMake или директория для генерации CMake. Настройки можно указать в File | Other Settings | Settings for New Projects…
Из важных улучшений проектной модели CMake еще стоит указать возможность перезагружать валидные конфигурации, даже если в проекте присутствуют другие невалидные. Это может быть полезно, если у вас настроено несколько удаленных конфигураций, которые на данный момент недоступны, но хочется перезагрузить хотя бы локальные конфигурации.
В отладчиках мы решили починить те проблемы и недоделки, которые беспокоят наших пользователей больше всего. Во-первых, CLion теперь читает .gdbinit/.lldbinit из директории проекта. Это полезно, если хочется какие-то настройки отладчика кастомизировать или добавить pretty printers, но только для конкретного проекта. Ранее приходилось эти настройки указывать в конфигурационных файлах отладчика в пользовательской директории. Теперь можно настраивать эти параметры специфично для проекта. Но, чтобы это заработало, надо разрешить такое поведение в самом отладчике в настройках на уровне пользовательской директории (читайте, как это сделать для GDB и как для LLDB).
Интеграция с LLDB доступна на Linux и macOS. В новом релизе мы проадейтили встроенный LLDB до версии 9.0, а заодно глобально пересмотрели все встроенные pretty printers. Благодаря этому существенно улучшилось представление стандартных контейнеров на обеих платформах. Подробные сравнительные таблички можно посмотреть в нашем англоязычном блоге. Стоит отметить, что на платформе macOS, библиотека libc++ обрабатывается гораздо лучше, чем libstdcxx. Это вроде бы соответствует популярности данных библиотек на этой платформе, но если вы используете libstdcxx на macOS, пожалуйста, расскажите в комментариях поподробнее о таких случаях.
В CLion сейчас существует несколько вариантов удаленной работы с проектом и отладки. От полностью удаленного варианта, когда и сборка, и отладка проекта происходят на удаленной машине, до вариантов, когда удаленно происходит только отладка проекта. Вот именно для второго случая мы добавили еще одну конфигурацию в CLion — Remote GDB Server. В отличие от имеющейся уже давно GDB Remote Debug (да, с названиями у нас не задалось, согласны), в новой конфигурации CLion сам собирает проект (возможно, при этом вам надо настроить параметры кросс-компиляции), загружает исполняемый файл на удаленную машину и запускает вашу программу под указанным gdbserver. Старая конфигурация больше теперь подходит для сложных вариантов, когда код на одной машине, сборка на второй, а отладка на третьей. Или если невозможна кросс-компиляция.
Да, это случилось! Мы наконец добавили отдельное действие для переключения между заголовочными и сорс-файлами. В чем же главное отличие от старого платформенного Go to Related Symbol? Дело в том, что, будучи общим платформенным действием, Go to Related Symbol старается быть очень точным и подобрать один самый верный вариант. Это и долго, и не всегда правильно в случае C++. Новое действие Go to Header/Source ведет себя иначе:
Стоит отметить особенность поиска (так как с ней уже встречались наши пользователи) — поиск сейчас ведется по непосредственно включенным/включающим файлам. Это временное ограничение, которое необходимо, чтобы не путать символы с одинаковыми именами из разных таргетов.
В анализаторе кода в CLion появилась новая проверка. Она отлавливает ситуации, когда виртуальные функции вызываются из конструкторов или деструкторов. Почему это плохо, уже много где обсуждалось. Теперь и CLion предупреждает о таких случаях:
Spell Checker — неотъемлемый компонент интегрированной среды разработки. Все мы делаем ошибки в правописании, а потом нашим коллегам тяжело читать код и комментарии. Поэтому хорошо, когда IDE подсвечивает такие ошибки. В этом релизе мы включили проверку правописания в файлах CMake и комментариях документации формата Doxygen:
Меньше ошибок правописания — более читаемый код!
Наша команда вкладывает сейчас большие усилия в языковой движок на основе Clangd. А мировое сообщество C++ активно развивает Clang. В этом релизе мы объединили усилия — взяли экспериментальную ветку Clang с поддержкой концептов из C++20, которую развивает Saar Raz, и влили ее в нашу ветку Clangd. Таким образом, мы получили подсветку кода с концептами и базовые проверки анализатора Clang в CLion:
Но на этом мы не остановились. И в нашем движке на базе Clangd мы реализовали некоторые полезные случаи автодополнения, проверку на использование концепта, рефакторинг Rename для концептов, действия навигации и поиска Go to Definition и Find Usages.
Автодополнение для параметров шаблона, на которые наложены ограничения:
Автодополнение для
Более подробно про нашу совместную работу над концептами можно почитать в англоязычном блоге. Там же есть видео-запись доклада с CppCon 2019, в котором Saar Raz презентовал свою реализацию концептов в Clang и нашу совместную работу по поддержке концептов в CLion.
Code coverage — возможность, которую очень ждали и просили пользователи CLion. В прошлом релизе работу в этом направлении начала команда AppCode, а в этом мы подхватили ее для случаев кросс-платформенного C++ уже в CLion.
Работают метрики покрытия кода в CLion через интеграцию с инструментами llvm-cov/gcov. При этом можно запускать как юнит-тесты, так и обычные конфигурации, и по их исполнению будет подсчитываться частота исполнения тех или иных строк кода. Результаты по нескольким запускам можно при желании суммировать в один общий.
Непосредственно результаты можно увидеть либо в специальном окне Coverage:
…либо в левом гаттере в редакторе.
Ну, и самое главное: чтобы это все заработало, требуется передать специальные параметры компиляции:
Почему CLion сам не передает эти параметры? В основном, потому, что у нас есть правило не вмешиваться в процесс компиляции. Да и не всегда понятно, куда передавать эти параметры в случае не CMake. Но сейчас мы думаем над вариантами того, как все же такие случаи в будущем автоматизировать (аналогичная проблема у нас есть и с санитайзерами).
Более подробно про опции компиляции и про отображение метрик в CLion можно почитать в нашем онлайн-хелпе.
Среди других важных улучшений в этом релизе:
В заключение, традиционный ролик о новых возможностях CLion 2019.3 (на английском):
Спасибо, что дочитали до конца! Наверняка у вас есть вопросы, пожелания, баг-репорты и просто мысли — ждем их в комментариях! Как всегда, с удовольствием ответим и обсудим ваши идеи.
Ваша команда JetBrains CLion
The Drive to Develop
Основной целью этого релиза было, как бы пафосно это ни прозвучало, качество. Мы решили сфокусироваться на проблемах, которые давно беспокоят наших пользователей, — в первую очередь, производительность и отзывчивость редактора, а во вторую — баги, недоделки и очень востребованные, но отсутствующие возможности.
Для начала, коротко о самом главном в этом релизе:
- Улучшения быстродействия и отзывчивости редактора, в первую очередь автодополнение, реализованное в нашем движке на базе Clangd.
- Ninja-генератор в CMake, настройки CMake по умолчанию и другие улучшения проектной модели.
- Обновления в интеграции с отладчиками.
- Новое действие для переключения между заголовочными и сорс-файлами.
- Более точный анализ кода: новая проверка для виртуальных функций, а также проверка правописания в CMake и в комментариях Doxygen.
- Поддержка концептов из стандарта C++20.
- Метрики покрытия кода.
- WSL2, правила форматирования и именования от Microsoft, обновления VCS поддержки и многое другое.
Ниже поговорим подробнее, но если вы готовы попробовать уже сейчас, то заходите и скачивайте билд с нашего сайта. Как обычно, доступна бесплатная пробная версия на 30 дней.
Быстродействие редактора
Судя по статистике, которую соглашаются нам присылать многие наши пользователи, самое часто используемое действие в CLion — это автодополнение. Именно на нем мы решили сосредоточить внимание в этом релизе, чтобы сделать его более отзывчивым. Для этого мы добавили к уже имеющимся в IDE «поставщикам» автодополнения еще один, на базе Clangd. Суть в том, что все поставщики работают параллельно, и, как только готовы первые результаты, CLion показывает раскрывающийся список вариантов, продолжая по мере надобности подгружать остальные варианты.
Конечно, мы захотели понять, дает ли преимущества такой гибридный подход. Замеры показали, что на простых проектах скорость собственного поставщика CLion и поставщика на основе Clangd отличаются не сильно. А вот на сложных проектах, таких как LLVM, Qt, Boost, Eigen, первые сто результатов от Clangd появляются существенно быстрее. Судите сами:
Подробнее о замерах — в отдельной статье в англоязычном блоге CLion.
Среди других значимых улучшений стоит отметить платформенное ускорение времени запуска IDE. Оно достигнуто за счет параллелизации многих процессов на старте, реорганизации классов, загружаемых на старте, оптимизации загрузки шрифтов на macOS. Конкретные числа для ускорения зависят от настроек окружения, машины, платформы и других факторов.
В 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 года.
Зато мы сделали самую долгожданную возможность в поддержке CMake — возможность указать любой генератор CMake, в том числе столь ожидаемый пользователями генератор Ninja! Раньше мы использовали Makefiles и похожие на него генераторы, так как парсили результирующие файлы (если точнее, это были -G “CodeBlocks – Unix Makefiles”, а на Windows -G "CodeBlocks – MinGW Makefiles" и -G "CodeBlocks – NMake Makefiles"). Теперь можно указать любой генератор в профиле CMake в CLion:
Это возможно только при использовании CMake версии 3.15 и выше, так как реализовано через CMake File API, и работает на всех платформах, в удаленном режиме, для WSL/WSL2.
Замечу, что такие генераторы как Xcode и Visual Studio являются мульти-генераторами, то есть генерируют файлы для всех типов сборок (Debug, Release и т. п.), но CLion для индексирования и сборки будет использовать только тот тип сборки, который указан в профиле CMake.
В этом релизе также появились настройки CMake по умолчанию. Это значит, что для всех новых проектов в CLion вы можете использовать одни заранее заданные настройки, такие как генератор CMake или директория для генерации CMake. Настройки можно указать в File | Other Settings | Settings for New Projects…
Из важных улучшений проектной модели CMake еще стоит указать возможность перезагружать валидные конфигурации, даже если в проекте присутствуют другие невалидные. Это может быть полезно, если у вас настроено несколько удаленных конфигураций, которые на данный момент недоступны, но хочется перезагрузить хотя бы локальные конфигурации.
Обновление интеграции с отладчиками
В отладчиках мы решили починить те проблемы и недоделки, которые беспокоят наших пользователей больше всего. Во-первых, CLion теперь читает .gdbinit/.lldbinit из директории проекта. Это полезно, если хочется какие-то настройки отладчика кастомизировать или добавить pretty printers, но только для конкретного проекта. Ранее приходилось эти настройки указывать в конфигурационных файлах отладчика в пользовательской директории. Теперь можно настраивать эти параметры специфично для проекта. Но, чтобы это заработало, надо разрешить такое поведение в самом отладчике в настройках на уровне пользовательской директории (читайте, как это сделать для GDB и как для LLDB).
Интеграция с LLDB доступна на Linux и macOS. В новом релизе мы проадейтили встроенный LLDB до версии 9.0, а заодно глобально пересмотрели все встроенные pretty printers. Благодаря этому существенно улучшилось представление стандартных контейнеров на обеих платформах. Подробные сравнительные таблички можно посмотреть в нашем англоязычном блоге. Стоит отметить, что на платформе macOS, библиотека libc++ обрабатывается гораздо лучше, чем libstdcxx. Это вроде бы соответствует популярности данных библиотек на этой платформе, но если вы используете libstdcxx на macOS, пожалуйста, расскажите в комментариях поподробнее о таких случаях.
В CLion сейчас существует несколько вариантов удаленной работы с проектом и отладки. От полностью удаленного варианта, когда и сборка, и отладка проекта происходят на удаленной машине, до вариантов, когда удаленно происходит только отладка проекта. Вот именно для второго случая мы добавили еще одну конфигурацию в CLion — Remote GDB Server. В отличие от имеющейся уже давно GDB Remote Debug (да, с названиями у нас не задалось, согласны), в новой конфигурации CLion сам собирает проект (возможно, при этом вам надо настроить параметры кросс-компиляции), загружает исполняемый файл на удаленную машину и запускает вашу программу под указанным gdbserver. Старая конфигурация больше теперь подходит для сложных вариантов, когда код на одной машине, сборка на второй, а отладка на третьей. Или если невозможна кросс-компиляция.
Go to Header/Source files
Да, это случилось! Мы наконец добавили отдельное действие для переключения между заголовочными и сорс-файлами. В чем же главное отличие от старого платформенного Go to Related Symbol? Дело в том, что, будучи общим платформенным действием, Go to Related Symbol старается быть очень точным и подобрать один самый верный вариант. Это и долго, и не всегда правильно в случае C++. Новое действие Go to Header/Source ведет себя иначе:
- Если за 500 мс не находится один единственно верный вариант, то появляется выпадающий список подходящих вариантов, из которых пользователь может выбрать наиболее подходящий.
- Если пользователь уже переходил из этого файла, то файл, куда он переходил, будет вверху списка.
- Дальше в списке будут файлы из этой же директории с совпадающим именем.
- И затем уже будут идти результаты поиска по сопоставлению деклараций и дефиниций.
Стоит отметить особенность поиска (так как с ней уже встречались наши пользователи) — поиск сейчас ведется по непосредственно включенным/включающим файлам. Это временное ограничение, которое необходимо, чтобы не путать символы с одинаковыми именами из разных таргетов.
Анализ кода
В анализаторе кода в CLion появилась новая проверка. Она отлавливает ситуации, когда виртуальные функции вызываются из конструкторов или деструкторов. Почему это плохо, уже много где обсуждалось. Теперь и CLion предупреждает о таких случаях:
Spell Checker — неотъемлемый компонент интегрированной среды разработки. Все мы делаем ошибки в правописании, а потом нашим коллегам тяжело читать код и комментарии. Поэтому хорошо, когда IDE подсвечивает такие ошибки. В этом релизе мы включили проверку правописания в файлах CMake и комментариях документации формата Doxygen:
Меньше ошибок правописания — более читаемый код!
Концепты из 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
