Привет!
Лето за окном пролетает для нас почти незаметно, потому что все эти месяцы мы посвятили работе над новым релизом 2019.2 нашей кросс-платформенной среды для разработки на C++ — CLion. Мы успели довольно много всего: и провести внутренний Хакатон, и попробовать новые идеи, и довести ряд исправлений и новых возможностей до непосредственного релиза. Но обо всем по порядку.
Если коротко, то в этом релизе мы:
- Продолжили дорабатывать поддержку разработки встроенных систем: появились новые возможности отладки и просмотр периферии.
- Довели до приемлемого качества пока что экспериментальный отладчик для MSVC.
- Полностью переписали на clangd проверку кода на Unused Includes, добавив возможность настраивать разные стратегии.
- Реализовали подсказки для аргументов вызова функций и лямбд, чтобы улучшить читаемость кода.
- Провели внутрикомандный Хакатон по улучшению производительности, придумали кучу новых подходов и успели воплотить в жизнь несколько улучшений.
- Реализовали подсветку синтаксиса более чем для 20 языков, встроили плагин для написания скриптов (Shell Script plugin), обновили плагин для Rust.
Это, конечно, тоже не все. Ниже поговорим подробнее, но если вы готовы попробовать уже сейчас, то заходите и скачивайте билд с нашего сайта. Как обычно, доступна бесплатная пробная версия на 30 дней.
Новые возможности для встроенной разработки
В прошлом релизе почему-то многим показалось, что мы сфокусированы только на STM32-платах. Это, конечно, по многим исследованиям (включая наше внутреннее) один из наиболее интересных и обширных рынков, но мы сейчас пытаемся решать и более общие задачи. Вот, например, расширили возможности отладки на различных платах из CLion.
Раньше единственной возможностью была конфигурация для отладчика OpenOCD — OpenOCD Download & Run. Теперь появилась еще одна — Embedded GDB Server. По сути, если плата поддерживает отладку через какой-либо совместимый сервер GDB, вы сможете отлаживать на ней через CLion. Конфигурация покрывает такие случаи, как OpenOCD, ST-Link GDB Servers, Segger J-Link GDB Server, QEMU и не только.
Достаточно создать и настроить соответствующую конфигурацию — указать путь до сервера GDB, аргументы, которые ему передать, возможно, какие-то более продвинутые настройки. Теперь запускайте отладку в данной конфигурации, и можно отлаживать на плате прямо из CLion!
Есть одно важное ограничение, которое действует сейчас на обе конфигурации для отладки встроенных систем, — они обе пока что работают только с проектами на CMake. В будущем мы планируем добавить возможность запускать их для кастомных проектных моделей (CPP-16079).
Для обеих существующих теперь конфигураций отладки встроенных систем (Embedded GDB Server и OpenOCD Download & Run) в новом релизе появилась возможность просмотра периферии при отладки. В целом, периферия специфицирована для устройств семейства ARM, в файлах формата .svd. Именно эти спецификации можно теперь подгрузить в CLion и просматривать выбранную периферию прямо в окне отладчика:
Вся периферия пока доступна в режиме только чтения, при этом есть поиск по названиям, возможность просматривать значения в разных режимах (шестнадцатеричном, десятичном, восьмеричном и бинарном). Чуть подробнее про это можно почитать в нашем блоге (на английском).
Экспериментальный отладчик для MSVC
Вы все правильно прочитали — в релизе 2019.2 в CLion появился экспериментальный отладчик для кода, скомпилированного с помощью MSVC! Теперь давайте разбираться чуть более детально и по порядку.
Уже давно в CLion можно при разработке на платформе Windows использовать не только тулчейн MinGW и Cygwin, но и Visual Studio. Вы указываете в CLion путь до установленной VS, а мы оттуда берем компилятор MSVC и скрипты для настройки окружения. Но вот с отладчиком долгое время были проблемы. Дело в том, что тот отладчик, который использует сама Visual Studio, проприетарный. Проще говоря, нигде, кроме инструментов Microsoft, его по лицензии использовать нельзя. Есть альтернативная технология — dbgeng.dll, на которой реализованы отладчики CDB и WinGDB. Мы первым делом опробовали ее. Но нам показалось, что бороться с количеством критических падений и плохой производительностью на бинарниках с больших количеством PDB-файлов не очень перспективно (хотя мы поначалу пытались). И тут выяснилось, что есть третий вариант — реализовать отладчик поверх LLDB. Там уже были наработки, и нам оставалось только продолжить эту работу. Что мы и сделали! Кстати, основные наши изменения (кроме пока что поддержки нативных визуализаторов данных) мы все положили в мастер LLVM.
Как включить? Как я уже писала, возможность пока экспериментальная. Отладчик еще рано называть полноценным, в нем множество ограничений и недоделок, да и производительность требует значительных оптимизаций. Эта экспериментальная возможность включается в диалоге Maintenance (Shift+Ctrl+Alt+/ на Linux/Windows, ⌥⇧⌘/ на macOS) | Experimental features | cidr.debugger.lldb.windows. Теперь для тулчейна Visual Studio доступен новый отладчик:
В отладчике есть начальная поддержка нативных визуализаторов, как поставляемых со студией, так и пользовательских кастомных, найденных в проекте. Пока что возможность требует явного включения в настройках: Settings | Build, Execution, Deployment | Debugger Data Views | Enable NatVis renderers for LLDB. В одном из первых апдейтов мы планируем поправить несколько критических проблем с визуализаторами и тогда, вероятно, включить их по умолчанию.
Если вы планируете попробовать новый экспериментальный отладчик, рекомендуем ознакомиться со списком известных ограничений и проблем в нашем блоге.
Другие улучшения в отладчике
Помимо нового экспериментального отладчика, мы провели ряд других улучшений:
- Во встроенной консоли GDB/LLDB в окне отладчика в CLion теперь работает автодополнение команд самого отладчика (используйте
TabилиCtrl+Space). - Строковые точки останова теперь валидируются на лету, и их статус обновляется и показывается пользователю в виде соответствующей иконки. Самым интересным типом является Invalid, который был добавлен, чтобы идентифицировать те точки останова, которые не доступны в текущем исполняемом коде или для которых отсутствуют отладочные символы (в этом случае после их подгрузки статус точки останова автоматически обновится):
- При просмотре памяти в отладчике (Memory View) в новой версии появилась возможность перейти на произвольный адрес (по числовому адресу или имени/адресу переменной), а также представление памяти в формате ASCII:
Улучшения в редакторе кода
В этой области больших улучшений сразу несколько. Во-первых, мы полностью переписали проверку кода Unused Includes и включили ее по умолчанию. Раньше она тоже была, но давала большое количество ложных срабатываний, поэтому мы выключили ее по умолчанию. Почему же стало лучше? Мы полностью переписали проверку на базе второго дополнительного инструмента для парсинга кода, который, в свою очередь, основан на Clangd. Так что отсюда понятное ограничение — работать новая версия будет, только если Clangd у вас не отключен (по умолчанию он включен). Зато теперь в проверке на Unused Includes появилось несколько стратегий, между которыми можно выбирать:
По умолчанию используется Detect not directly used, которая по сути наиболее близка к известному принципу Include What You Use, то есть, если декларации из заголовочного файла не используются в данном файле напрямую, то такой заголовочный файл помечается как неиспользуемый.
В настройках инспекции (Settings / Preferences | Editor | Inspections | C/C++ | Unused code | Unused include directive) можно также выбрать, запускать ли проверку в самих заголовочных файлах. Она, правда, будет работать только в тех заголовочных файлах, где присутствуют #pragma или header guards конструкции. А еще важно знать, что, если в исходном файле присутствуют ошибки компиляции, то проверка не покажет неиспользуемых файлов.
С прошлого релиза CLion поддерживает ClangFormat как альтернативный инструмент форматирования кода, в дополнение ко встроенному. В этой версии мы добавили встроенную схему JSON для конфигурационных файлов .clang-format. И благодаря этому сумели добавить несколько возможностей, которые могут быть полезны тем, кто будет изменять файлы .clang-format в CLion:
- Появилось автодополнение для опций и их значений.
- В окне автодополнения для опций присутствует теперь описание опций.
- Окно документации Quick Documentation (
Ctrl+Qна Windows/Linux,F1на macOS) показывает документацию на опции и их значения, с примерами. - Добавлена проверка значений опций на допустимые.
Подсказки для аргументов
Что делать, если функция написана (возможно, не вами) так, что в качестве аргументов ей передается 3 целых числа? Как понять по вызову функции, что же значат передаваемые значения? Конечно, можно посмотреть сигнатуру функции в окне документации, перейти на определение функции или вызвать информацию о параметрах (Parameter Info). А если не делать этих явных действий?
В версии CLion 2019.2 появились подсказки для аргументов — при вызове функции, лямбды, конструктора, списка инициализаций или при использовании макроса CLion показывает имена параметров перед переданными аргументами: 
Подсказки показываются в тех случаях, когда действительно сложно понять, какие значения каким параметрам передаются, а именно, в случае использования в качестве аргументов вызова литералов или выражений более чем с одним операндом. Подробнее в блогпосте.
Производительность
Конечно, нас часто спрашивают про улучшения производительности. Я повторюсь, для нас это наиболее приоритетная задача, но точечных изменений получается сделать не много, а глобальные требуют времени больше, чем 1-2 релизных цикла. Сейчас в работе несколько таких больших изменений. В основном, они связаны с тем, как парсер в CLion взаимодействует с архитектурой платформы (которая не всегда рассчитывает, что за простым действием, в случае C++, скрывается долгий резолв кода).
Этим летом мы с командой решили провести внутренний Хакатон, чтобы определить наиболее уязвимые места в архитектуре CLion и платформы, попробовать новые смелые идеи и проверить некоторые давние гипотезы. Результаты нам понравились. По возможности, мы планируем довести какие-то новые идеи до релиза уже к 2019.3.
Но и релиз 2019.2 не остался без улучшений производительности:
- Мы избавились от многих замедлений и зависаний в рефакторинге In-place Rename.
- Улучшена производительность автодополнения для квалифицированных выражений.
- В случае удаленной работы, мы уменьшили количество операций ввода/вывода, чем значительно ускорили сбор информации о компиляторе, а, значит, и скорость загрузки проекта CMake.
- И другие улучшения.
Не только C++
Из платформы IntelliJ в CLion 2019.2 перешло множество улучшений для работы с другими языками.
Подсветка синтаксиса более 20 языков теперь обеспечивается за счет грамматик TextMate (полный список языков можно найти в Settings/Preferences | Editor | TextMate Bundles). Конечно, если для данного языка есть расширенная поддержка в CLion (Python, JavaScript, HTML, Objective-C, SQL), то она и будет использоваться, но для таких языков, как например, Ruby, может быть полезна и простейшая подсветка:
Часто в проектах на C++ встречаются разнообразные скрипты. Плагин для поддержки написания скриптов (Shell Script plugin) теперь встроен в CLion. Он обеспечивает не только подсветку кода, но и автодополнение и текстовое переименование:
Плагин для языка Rust получил множество полезных обновлений. От нового экспериментального инструмента для раскрытия макросов (Settings/Preferences | Languages & Frameworks | Rust | Expand declarative macros) до проверки на Duplicate code fragments, различных новых быстрых исправлений (quick-fixes) и автодополнения в отладчике в Evaluate Expressions. Кстати, именно в CLion сейчас наибольшее использование данного плагина среди всех IDE от JetBrains!
Демо
Традиционный ролик о новых возможностях CLion 2019.2 (на английском):
На этом всё на этот раз. Спасибо, что дочитали до конца! Вопросы, пожелания, баг-репорты и просто мысли высказывайте в комментариях! Мы, как и всегда, будем рады ответить.
Ваша команда JetBrains CLion
The Drive to Develop
Автор: Казакова Анастасия
