Привет, Хабр!

Традиционно начало декабря — время, когда релизятся все продукты JetBrains. И сегодня я расскажу о CLion 2021.3 — новой версии нашей кроссплатформенной IDE для разработки на C и C++.

Решения для удаленной разработки

Главная новость прошедшей релизной недели — выпуск нового решения для удаленной разработки. Его модель предполагает, что исходный код, тулчейн и бэкенд IDE находятся на удаленном сервере, а для взаимодействия с IDE используется тонкий клиент, запущенный на локальной машине. Таким образом решается несколько проблем:

  • Вам не нужно загружать код на локальную машину. Он хранится на удаленном (и, вероятно, защищенном) сервере — вам просто нужно подключиться к нему.

  • Локальной машине не обязательно быть мощной, так как бэкенд IDE запускается на удаленной машине.

  • Вам не придется тратить время на настройку окружения. Достаточно один раз настроить набор стандартных сред, после чего ваша команда сможет ими пользоваться. В будущем, если среда «прогрета», вам даже не придется даже ждать окончания индексации — просто открывайте локальный клиент, подключайтесь и сразу приступайте к работе.

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

Другие обновления в CLion 2021.3

Следующие улучшения будут полезны независимо от используемой вами платформы и специфики разработки:

  • работа с тулчейнами — оптимизация и новые возможности;

  • отладчик — улучшенное представление данных;

  • редактор — подсказки для выведенных типов;

  • анализ кода — повышение точности и новые возможности;

  • новая опция для представления структуры текущего файла.

А теперь разберем все в деталях.

Тулчейны

Мы поддержали новый тип тулчейна для работы с контейнерами Docker. Раньше мы предлагали использовать для этого тулчейн Remote. Но копирование исходного кода в контейнер по ssh давало лишние накладные расходы. Новый тулчейн Docker просто монтирует директорию с проектом к контейнеру. Подробнее об особенностях работы нового тулчейна на Windows и о том, как его настроить на любой из платформ, рассказывает наш новый девелопер-адвокат Тимур Думлер (на английском):

Для пользователей Windows мы подготовили сразу несколько улучшений:

  • MinGW теперь включен в поставку CLion, чтобы сэкономить время на предварительную конфигурацию окружения тем, кто только начинает работу в CLion. В настоящее время в CLion встроена версия MinGW-w64 9.0 с параметром languages=c,c++, потоками POSIX и структурированной обработкой исключений (SEH).

  • Тулчейн System позволяет настроить исполняемые файлы для CMake, компилятора и отладчика, не указывая заранее настроенное окружение (MinGW, Cygwin, WSL, Visual Studio и пр.). Версия тулчейна для Windows работает аналогично версиям для Linux и macOS.

Также есть несколько важных улучшений для разработчиков встроенных систем. Появилась опция Custom Compiler, позволяющая использовать компиляторы, которые не поддерживаются из коробки. Теперь таким компиляторам не придется «маскироваться» под GCC или Clang. Достаточно прописать компиляторные определения в файле формата *.yaml и указать этот файл в настройках Settings/Preferences | Build, Execution, Deployment | Toolchains | Custom Defined Compiler:

Теперь CLion умеет работать с заданными таким образом компиляторами. Мы создали специальный GitHub-репозиторий, в который будем добавлять конфигурационные файлы для популярных компиляторов. Некоторые из них мы уже добавили:

В некоторых случаях окружение компилятора можно настроить с помощью скрипта. В нем вы сможете инициализировать переменные окружения, настроить переменную PATH и пр. Теперь CLion позволяет указать такой скрипт в настройках тулчейна и исполняет его при первом запуске тулчейна. Кстати, похоже, что таким образом можно научить CLion работать с новым компилятором от Intel на базе LLVM. Мы еще не до конца исследовали этот вопрос, но пока тестирование проходит успешно.

Большинство наших пользователей предпочитает работать над проектами CMake (тогда как CLion также еще поддерживает Makefile, compilation database, и совместим с плагинами для Gradle и Bazel). В качестве генератора CMake большинство пользователей предпочитают Ninja. CLion 2021.3 включает Ninja v1.10.2. Если вы откроете или создадите проект в CLion с CMake v3.20+, то при запуске локальных тулчейнов по умолчанию будет использован именно Ninja. Управлять используемым в CMake генератором теперь можно не только через опции CMake, но и из интерфейса CLion: Settings/Preferences | Build, Execution, Deployment | CMake.

Отладчик

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

Например, можно не отображать в окне отладчика вспомогательные пространства имен, глобальные спецификаторы и спецификаторы для областей доступа отдельных функций, а также пространства имен версии ABI стандартной библиотеки. Можно вообще не отображать типы. Посмотрите, насколько существенным может быть отличие:

В окне фреймов можно убрать тип возвращаемого значения функции, скрыть ее параметры и аргументы шаблона. Также можно и добавлять: например, добавьте имя модуля, чтобы видеть, какой файл выполняется в данный момент времени и какой идентификатор потока передан ОС при запуске:

Новое действие View as Array доступно для всех переменных типа указатель. Оно добавляет представление значение указателя в виде массива в список просматриваемых переменных. Чтобы запустить действие, откройте контекстное меню для переменной и укажите размер массива:

В прошлой версии CLion шестнадцатеричное представление числовых переменных было экспериментальной функцией. В новой версии мы улучшили эту возможность и добавили ее на страницу настроек. Также появилась возможность просмотра параллельных стеков при отладке многопоточных приложений. А встроенный LLDB был обновлен до 13-й версии.

Также мы добавили ряд важных улучшений для разработчиков встроенных систем на базе RTOS. Помимо FreeRTOS, CLion теперь поддерживает Zephyr RTOS. Что касается FreeRTOS, мы поддержали дополнительные таблицы — для просмотра выполняющихся задач, активных очередей, программных таймеров, а также использования кучи и распределения блоков памяти:

Подсказки для выведенных типов

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

Анализ кода

Мы обновили инструменты LLVM до версии 14.0.0. Это касается как кастомизированного нами языкового движка Clangd, так и инструментов Clang-Tidy и ClangFormat. Благодаря этому языковые функции работают точнее, а демон Clangd — реже падает. Также в анализаторе Clang-Tidy появились новые проверки — сразу после обновления версии CLion спросит вас, какие из них вам нужны.

В прошлых релизах мы перевели анализ потока данных (DFA) на Clangd и реализовали его в глобальном контексте (то есть не просто в теле функции, а в рамках единицы трансляции). В новом релизе разные вызовы функций рассматриваются по-разному: параметры и возвращаемые значения для разных точек вызова анализируются отдельно. Это уменьшило количество ложных срабатываний анализатора и повысило точность его работы. Вот типичный пример с поиском подвисшего указателя (dangling pointer):

К слову, мы улучшили анализ времени жизни объекта (реализован в CLion через DFA на основе предложения Герба Саттера Lifetime Safety), и теперь он отлавливает больше проблемных случаев.

Мы продолжаем работу по поддержке MISRA C 2012 и MISRA C++ 2008 в CLion. В этом релизе добавилось много новых проверок. Полный список доступен по ссылке. В следующем году планируем, вероятно, добраться и до спецификации AUTOSAR.

Структура текущего файла

В новой версии CLion квалифицированные имена функций-членов отображаются полностью. Благодаря этому при анализе структуры файла в окне Structure вы сможете легко различать функции с одинаковыми именами. Настроить отображение можно с помощью специальной настройки в верхней панели:

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

В качестве эпилога

На этом у нас все. Если вы дочитали до конца, напишите в комментариях ваше любимое сочетание клавиш в CLion :) (Я так пишу каждый релиз, но пока никто не поделился с нами в комментариях любимым сочетанием... Кто же станет первым?)

Новую версию можно скачать на нашем сайте и попробовать бесплатно в течение 30 дней. Если у вас есть активная подписка на CLion или All Products Pack, просто обновите версию до 2021.3. Напоминаем, что при покупке годовой подписки на любой продукт JetBrains вы получите резервную бессрочную лицензию.

Оставляйте ваши вопросы, мысли и предложения в комментариях — нам интересно, что вы думаете, и мы всегда рады помочь!

Команда CLion
The Drive to Develop

Комментарии (22)


  1. gudvinr
    14.12.2021 17:30

    У remote тулчейнов есть один нюанс, о котором нигде не написано:
    Приложения, собранные этим тулчейном запускаются тоже в этом remote окружении и это никак нельзя изменить.


    Почему это важно? Потому что на C++ пишется не только бэкенд, когда это в принципе оправдано, и при этом среда сборки не обязательно должна совпадать со средой выполнения.
    И довольно легко иметь окружение в Docker, которое будет собирать полностью статичные бинарники (либо упаковывать разделяемые библиотеки вместе с приложением), но будет бесполезно для выполнения.
    Например, это характерно для GUI приложений, игр и вообще всего что связано с выводом на экран.
    В таком случае удобно иметь стабильное окружение для сборки в docker, но запускать локально.


    1. boblenin
      14.12.2021 20:08

      Все так, хотя для игр это может тоже применяться. Мы рассматривали возможность запуска и отладки игровых клиентов на удаленных машинах когда начались локдауны.


    1. anastasiak2512 Автор
      14.12.2021 20:33

      У нас, кажется, в документации все же указано, что в удаленном режиме все удаленно и запускается.

      Вообще для более сложных сетапов, когда сборка и запуск на разных машинах, есть общий подход, описанный тут. По сути, в случае запуска локально, там даже проще. Есть локальная конфигурация для запуска и удаленная для сборки. А также external tool настраиваете, чтобы скачивать бинарь с удаленной машины на локальную. Вроде должно норм работать.


    1. bac1ca
      15.12.2021 13:09

      Конкретно с докером никаких дополнительных телодвижений не нужно, по сути бинарь и все остальные артефакты сборки складываются в приаттаченный volume, т.е. в корень проекта (cmake-build-debug-xxx) и доступны для последующующего локального запуска. Можно создать локальную run-configuration у контрой убрать build-step, а в качестве executable указать бинарь собранный в докере.


  1. boblenin
    14.12.2021 20:05
    +1

    То, что включили mingw в стандартную поставку - спасибо, доустановить ее не особая проблема, но все-таки мелкое неудобство, а как потом в него добавить библиотеки или, например интегрировать с QT?


    1. anastasiak2512 Автор
      14.12.2021 23:58
      +1

      Это хороший вопрос) Спасибо. Мы про него думали и видим, конечно, определенную сложность. Для QT можно установить официальный дистрибутив, указав в компонентах MinGW 64-bit, дальше сконфигурировать в CMake. CLion темплейты Qt проектов (console/gui) работают из коробки, если указать QT через CMAKE_PREFIX_PATH (по умолчанию MinGW 64-bit QT ставится в "C:/Qt/Qt5.12.12/5.12.12/mingw73_64").
      В случаях других библиотек, там только через поиск библиотеки в CMake подключать. Но для тех, кто хочет побыстрее начать разработку в пустом окружении, бандленный mingw все равно перевешивает по удобству.


  1. avengerweb
    15.12.2021 02:11

    А где то есть почитать насколько все эти remote чувствительны к задержке, к примеру, клиент в Европе, сервер в США. Ну или даже банально лаптоп на WiFi с телефона? Возможно ли будет работать в таком сетапе?


    1. anastasiak2512 Автор
      15.12.2021 15:41

      В целом, JetBrains Client подразумевает редактор, работающий на основе протокола JetBrains Rider’s RD (это как раз протокол, который использует наш продукт Rider для общения с бэкендом из ReSharper-а). Этот протокол оптимизирован так, чтобы тайпинг ощущался мгновенным. Умная работа с кодом происходит на стороне сервера IntelliJ IDEA и организована так, чтобы ощущалась как локальный инстанс.

      Но тут, конечно, многое зависит от сети. И при каких-то больших пингах, понятно, что комплишен будет не мгновенный, и вообще будет не прямо как локально. В целом, у нас в тестировании все работает адекватно. Но при этом работа ведется и по части оптимизации latency.


  1. Showvars
    15.12.2021 08:16
    +1

    Использую с напарником режим remote для PyCharm и CLion. Первые впечатления конечно очень хорошие — идея и направление правильное. Но к сожалению, в процессе работы постоянно выскакивают всякие странности, например, клиент Gateway просто может зависнуть на всегда по не понятным мне причинам — иногда от открытия вкладки с файлом, иногда от дебага, а иногда при попытке использовать автодополнение и прочее. Спасает только диспетчер задач.

    Пинг сильно мешает, по крайней мере мне. Если больше 100, то работать очень не комфортно, задержки страшные, даже по инпуту. Хорошо что в моем далеком городе есть более менее адекватный хостинг с пингом <10. У Visual Studio Code с этим лучше, по моим ощущениям. А еще на боевых проектах, CLion очень много кушает ресурсов.

    Очень надеюсь на JetBrains Fleet. Если я правильно понял, там всё, включая remote, реализованы по другому.


    1. anastasiak2512 Автор
      15.12.2021 12:45

      Новое решение для удаленной разработки еще совсем новое) В смысле, что там пока, к сожалению, еще много разнообразных проблем. Подскажите, вы репортили те проблемы, которые наблюдаете, нам в трекер? Чтобы обратить внимание команды на них.


      1. Showvars
        16.12.2021 11:19

        Подскажите, вы репортили те проблемы, которые наблюдаете, нам в трекер? Чтобы обратить внимание команды на них.

        Нет, не репортил, поскольку там и так уже много сообщений, включая мои случаи.


  1. jaha33
    15.12.2021 12:09

    Планируете ли добавить какой нибудь готовый шаблон проекта для embedded? Чтобы на его основе можно было модифицировать проект.

    Либо например сделать как segger embedded studio, эта IDE позволяет в 2-3 клика импортировать проект из IAR/Eclipse. Это достаточно удобная вещь.


    1. anastasiak2512 Автор
      15.12.2021 12:42

      Шаблон для Embedded - очень расплывчатое понятие. Сейчас есть интеграция с STM32CubeMX проектами и с PlatformIO (если плагин поставить). Мы, конечно. хотели бы больше, но пока не понятно, что именно стоит сделать в первую очередь. Можете привести примеры, какие конкретно проекты еще хочется видеть?

      @Elmot может сможет что-то еще подсказать тут.


      1. jaha33
        15.12.2021 14:19

        Можно например: Сделать шаблон под самую распространенную архитектуру и ядро (например Cortex M0). В main сделать цикл, который по достижении определенного числа что то вызывает. Собирать все это через GCC ARM (т.к. он бесплатный). Что то подобное было бы удобно для старта нового проекта. Т.к. все пути и настройки уже подтянуты. Дальше уже меняем абстрактный Cortex M0 на конкретный чип, тулчейн если надо, подтягиваем линкер файл, .svd и вперед.

        У segger embedded studio примерно так и сделано.

        Просто лично мне не очень понравилось как это сейчас реализовано у вас, возможно потому что с вашими IDE никогда не работал и чего то не понимаю. Но те же segger embedded studio, eclipse, IAR позволяют создать готовый шаблон, где то абстрактный, где то под конкретный чип/семейство.


        1. anastasiak2512 Автор
          15.12.2021 15:42

          Ну вот PlatformIO как раз довольно много шаблонов для разных микроконтроллеров предлагает. При установке плагина, появляется как дополнительный пункт в диалоге создания нового проекта. Вы не пробовали?


          1. jaha33
            15.12.2021 16:43

            platformio создает проекты только под те платформы, которые поддерживает. И это не "чистый" .с проект, это экосистема для "упрощенной разработки". Серьезные проекты под ардуино обычно не делают)


            1. anastasiak2512 Автор
              16.12.2021 00:34

              Platformio не только Ардуино поддерживает. У них обширный список плат.


  1. Ritan
    15.12.2021 14:11

    В новой версии сломан дебаггер для моего проекта ещё начиная с первых EAP. Пока что решил для себя копией бинарей дебаггера от прошлой версии. Вроде как это баг в lldb, видел у вас на трекере. Что-то известно насчёт ETA?

    Индексация кода очень заметно ускорилась - теперь 2021.2 кажется очень медленной на контрасте. К сожалению это также частенько показывает ложные предупреждения о неиспользуемых переменных


    1. anastasiak2512 Автор
      15.12.2021 14:13

      А есть описание того, как именно сломан дебагер? Или ссылка на тикет?

      Аналогично про ложные срабатывания, есть тикет или пример?


      1. Ritan
        15.12.2021 15:42

        С дебаггером описывать особо нечего - просто при попытке поставить на паузу процесс или поставить breakpoint в некоторых местах, происходит SIGSEGV в самом lldb. Ни в логах ни в окне ошибок IDE - ничего нет

        С ложными срабатываниями - происходит не постоянно. Не уверен триггерится это при запуске или уже во время работы. Если найду какой-то более подходящий пример для воспроизведения - отпишусь.

        P.S. падение при установке бряков есть и в 2021.2, но гораздо реже - только если попытаться поставить точку в темплейтной функции, которая встречается в 100+ модулей. Видимо зависит от количества локаций в бинаре, куда нужно поставить останов.

        P.P.S

        void Process(const Foo* global, size_t index,
                        size_t& containers) const override
                    {
                        containers = 0;
                        for (auto& cont: Containers)
                        {
                            size_t container;
                            cont.second->Process(container, nullptr);
                            containers += container;
                        }
                    }

        В этом участке сообщает, что containers и cont не используются


        1. anastasiak2512 Автор
          16.12.2021 00:16

          Про отладчик, нам неизвестны такие проблемы в версии LLDB, которая в релизе. Там был краш, но мы его откатили, и аналогично в LLVM его недавно тоже ревертнули, но он выглядел иначе. Можете собрать логи по этой инструкции, пожалуйста, и создать тикет в трекере, приложив логи и описание проблемы?

          А вот падения, как вы описываете в 2021.2, похоже на то, что откатывали мы и LLVM. В общем, давайте разбираться с текущей проблемой на 2021.3, начнем с логов.


        1. anastasiak2512 Автор
          16.12.2021 00:32

          Спасибо за пример с ложным анализом. Сейчас посмотрим. У меня правда только container показывается как unused.