company_banner

CLion 2018.3: удаленная разработка, профилирование кода, быстродействие и не только

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

    На днях мы выпустили CLion 2018.3. Третий в этом году крупный релиз подытоживает нашу работу по двум важным направлениям развития — улучшению языковой поддержки и удаленной разработке.

    Кроме того, мы, наконец:

    • добавили средства профилирования кода;
    • переделали команды в редакторе для сборки/пересборки кода на уровне одного файла, нескольких таргетов или всего проекта целиком;
    • вместе с другими IDE на базе платформы IntelliJ добавили поддержку Git submodules и GitHub pull requests;
    • улучшили средства универсального доступа к возможностям IDE (accessibility).

    image

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

    Поддержка языка C++


    Больше С++17


    Парсер CLion научился понимать две новые возможности стандарта C++17 — fold expressions и deduction guides. С одной стороны, изменения в парсере — это еще не полная поддержка, но, как минимум, подсветка кода будет более правильная, а для случаев user-defined deduction guides IDE даже правильно выведет тип и его можно будет увидеть, например, при вызове информации о параметрах функции.

    image

    Clangd теперь и в навигации


    В прошлый раз мы писали о том, что CLion теперь использует не только собственный языковой движок для работы с кодом на C/C++, но и еще один дополнительный, экспериментальный, сделанный на основе Clangd. Включив его для показа ошибок и предупреждений в редакторе, мы двинулись дальше и в CLion 2018.3 реализовали на его основе некоторые действия навигации по коду и поиска в коде.

    Языковой движок на базе Clangd предоставляет результаты, которые впоследствии все равно объединяются с результатами, полученными из собственного движка CLion. Типичный пример — Find Usages (Alt+F7): по открытым в редакторе файлам поиск осуществляет Clangd, а по остальным — наш собственный движок.

    Примеры других действий, где дополнительно используется языковой движок на Clangd:

    • Go to declaration (Ctrl+B / ⌘B) / Go to definition (Ctrl+Alt+B / ⌥⌘B)
    • Подсветка всех включений символа, на котором стоит курсор
    • Quick Documentation (Ctrl+Q / F1)

    Clangd включен по умолчанию и настраивается в Settings/Preferences | Languages & Frameworks | C/C++ | Clangd:

    image

    То есть можно независимо включать/выключать необходимую функциональность поверх Clangd — например, только показ ошибок или только навигацию. Если нужно полностью отключить использование Clangd, снимите все галочки в этом диалоге.

    И, кстати, Clang-Tidy вполне можно запускать и без Clangd, но запуск через Clangd существенно улучшает производительность, так как использует AST-дерево, закешированное в Clangd.

    Удаленная разработка


    В релизе CLion 2018.1 появилась возможность на Windows работать с подсистемой Windows Subsystem for Linux (WSL). Это Linux-окружение, встроенное в Windows, позволяет собирать, запускать и отлаживать Linux-приложения на Windows. Мы тогда говорили, что специально реализовали поддержку WSL через ssh, то есть как удаленной подсистемы. Это был первый шаг к работе с полностью удаленными конфигурациями.

    И вот в CLion 2018.3 мы объявили о поддержке первого большого варианта удаленной разработки:

    • На локальной машине, где запускается CLion, может быть Linux, Windows или macOS.
    • На удаленной машине, где CLion будет осуществлять сборку вашего приложения, запускать и отлаживать его, исполнять тесты, — пока может быть только Linux.
    • Предполагается, что код находится на локальной машине. CLion сам синхронизирует его на удаленную машину, а обратно на локальную вытаскивает header search paths для быстрого резолва кода в редакторе. Синхронизация осуществляется через rsync для Linux или macOS в качестве локальных машин, и через sftp and gzip для Windows.
    • Работает пока что только для проектов на CMake.

    image

    Настроить такую удаленную конфигурацию очень легко — надо просто создать удаленный тулчейн в Settings/Preferences | Build, Execution, Deployment | Toolchains и использовать его в каком-нибудь CMake Profile. Подробная инструкция есть в нашем англоязычном блоге и в онлайн-документации. Прогресс синхронизации с удаленным хостом отображается в окне File Transfer (View | Tool Windows | File Transfer), а изменить параметры соединения и пути к директориям на удаленной машине — в настройках Settings/Preferences | Build, Execution, Deployment | Deployment.

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

    Анализ производительности пользовательского кода


    CLion 2018.3 дает возможность анализировать производительность кода. На Linux — предоставляется интеграция с Perf, на macOS — с DTrace. Новое действие доступно в меню Run, на панели навигации и в контекстном меню иконок запуска приложения. Результаты профилирования кода доступны в окне CPU Profiler (View | Tool Windows | CPU Profiler).

    image

    Подробно о том, что необходимо установить на компьютер, чтобы заработало профилирование кода, читайте в блоге или онлайн-документации.

    Стоит отметить, что UI/UX пока несколько экспериментальный. Его планируется существенно улучшать в версиях 2019.x. Но уже есть полезные штуки, вроде возможности посмотреть все треды вместе или по одному, возможность навигации на исходный код и др.

    Команды сборки и пересборки кода


    Количество разнообразных комбинаций команд сборки так выросло, что мы решили вынести их все в отдельный пункт меню — Build. Там и сборка/пересборка всего проекта, и таргета all из всех или из выбранного CMake профайла, и выбранной конфигурации, и одного конкретного файла:

    image

    Это, понятное дело, для CMake. Для compilation database там будет только команда пересборки конкретного файла.

    Универсальные диалоги: Run Anything и Search Everywhere


    С диалогом Search Everywhere (Double Shift) пользователи CLion знакомы давно, как и с диалогом Find Action (Ctrl+Shift+A / ⇧⌘A) для поиска команды или настройки по имени, и с диалогами навигации на файл, символ или класс по их имени. И вот теперь это, на самом деле, один и тот же диалог!

    image

    Отдельные диалоги превратились в отдельные вкладки, переключение работает через Tab. Заодно мы устранили ряд проблем, связанных с этими диалогами, в т. ч. потери фокуса и некорректные размеры.

    Другой новый универсальный диалог — Run Anything (Double Ctrl). Из него можно запустить приложение в обычном режиме или из-под отладчика, а также открыть любой проект:

    image

    Проверки в сompilation_database.json


    Compilation database — альтернативная проектная модель, которую уже некоторое время поддерживает CLion. Она очень удобна тем, что получить ее можно фактически из любой другой проектной модели, популярной или вообще кастомной. CLion умеет открывать проекты из compilation database, парсить правильно код и предоставлять все умные средства работы с кодом. Единственный минус — это отсутствие в данном формате информации о сборке всего проекта, так что собрать из IDE пока получится только отдельные файлы.

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

    image

    Проверки могут быть очень полезны, если вы-таки решили написать такой файл руками или подправить имеющийся файл.

    Производительность редактора и тесты


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

    Улучшения в редакторе


    Как известно, в окне Quick Documentation (Ctrl+Q / F1) CLion умеет показывать не только документацию и комментарии к коду, но и выведенные типы для переменных и финальную подстановку в макросах. Эта финальная подстановка теперь отформатирована, и в ней подсвечиваются ключевые слова. Очень удобно для сложных макросов с несколькими уровнями вложения, например для Boost:

    image

    Комментарии TODO теперь можно делать многострочными, главное соблюсти отступ для второй и последующих строк — CLion автоматически поймет, что это часть комментария TODO:

    image

    Есть пользователи, для которых стандартные темы не удобны, так как не обладают достаточной контрастностью. Для них мы добавили специальную High-contrast Theme. Ее можно включить только в редакторе кода (Ctrl+`) или же для всей IDE (Settings/Preferences | Appearance & Behavior | Appearance | Theme).

    image

    Вместе с IntelliJ Platform мы переработали меню настроек плагинов в IDE (Settings/Preferences | Plugins). Теперь гораздо проще поддерживать установленные плагины в актуальном состоянии, а также сортировать и фильтровать огромный репозиторий существующих плагинов для IDE.

    Система контроля версий


    Еще одно важное платформенное изменение — это долгожданная поддержка Git submodules. Теперь все операции для работы с VCS в CLion учитывают и подмодули: клонирование проекта, его обновление, сравнения версий (diff) и пр.

    Добавилось окно GitHub Pull Requests, в котором можно не только просмотреть все pull requests, но и искать/фильтровать их по автору или состоянию. А еще можно создать новую ветку из любого pull request буквально в один клик.

    Демо


    Традиционное видео о новых возможностях CLion 2018.3 на английском языке:


    Что же дальше?


    В следующем году мы планируем продолжать работу над вторым дополнительным языковым движком на базе Clangd — посмотрим, какие еще возможности IDE мы сможем на нем реализовать. Будем улучшать производительность редактора, доделывать и улучшать имеющиеся фичи; особенно разнообразной выглядит работа по поддержке удаленной разработки в CLion. Из интеграций планируем clang-format и, вероятно, тот или иной отладчик для Windows/MSVC.

    А ключевым направлением для нас станет Embedded-разработка. Совсем недавно к нашей команде присоединился Elmot, автор очень популярного плагина для поддержки в CLion OpenOCD + STM32CubeMX. Илья будет продолжать интегрировать эту функциональность в IDE, мы же планируем в самое ближайшее время доделать memory view и переделать hex view.

    Вопросы, пожелания, баг-репорты и просто мысли высказывайте в комментариях! Мы будем рады ответить.

    Ваша команда JetBrains CLion
    The Drive to Develop
    JetBrains
    222,00
    Делаем эффективные инструменты для разработчиков
    Поделиться публикацией

    Похожие публикации

    Комментарии 60

      +3
      Ребяяяяяяят, ну дайте уже Community Edition пжлста.
        0
        Вынуждена разочаровать — пока таких планов у нас нет.
          0
          Жаль конечно, но всё равно мы все очень любим ваши инструменты!!!
            0
            Спасибо за поддержку!
              0
              Для любых наших IDE есть вариант, как платить не ноль, но очень мало: сидите на ЕАПах, а в те месяцы, когда их нет – покупайте месячную подписку. Итого это выйдет примерно три (ну, окей, четыре) платных месяца в год. Получается, 48 долларов в год, то есть 250 рублей в месяц :) Точно так уж нужна комьюнити?
                0

                Летом тут за те же ~45 баксов раздавали годичную лицензию.

                  0
                  Ну да, или скидки ловить.
                    0
                    Что такое ЕАП?
                      0
                      Early Access Program — превью будущих версий. Нестабильные, но бесплатные билды, которые можно качать с сайта и пробовать последние изменения.
              0
              Можно узнать причины?
                0
                Чтобы делать коммьюнити версию нужны веские причины и обстоятельства, мы их пока не видим в случае CLion/C++.
                0

                Планов нет или все-таки не решена бизнес-модель что продать из инструмента CLion.
                Предлагаю убрать:


                1. поддержку всех видов Make(GNU autotools, GNU make, meson, CMake, etc.);
                2. поддержку проектов Visual Studio(если была);
                3. perf;
                4. clangd;
                5. удаленную разработку;

                Ограничить: настройки как это сделано в Intelij IDEA и PyCharm (соответствующих редакций);


                Это и будет Community Edition для CLion.
                P. S. И никаких веских причин кроме экономических не надо. Будем честны перед потребителями.
                Плюс с потребителей Community Edition берите деньгу за техподдержку и доступ к специальному репозиторию необходимого функционала.

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

                    Рад, что JetBrains принципиальна.


                    А без того же clangd поддержка языка очень страдает.

                    Для комьюнити версии нейтрализация clangd не вызовет особых страданий у потребителей ведь не всегда им нужен code completion. (Да, я отчасти не всегда на стороне потребителя.)


                    В общем, спасибо за предложение, но пока кажется, что это не релевантно.

                    Оно окажет отклик лишь после тестового введения комьюнити версии с опросом пользователей.

                      0
                      Я не соглашусь про clangd — он сейчас используется для показа ошибок и предупреждений, и сильно помогает особенно в случае использования фич языковых, которые не поддерживает наш собственной движок пока. Ну и мы в целом планируем попробовать довольно много фич в будущем перевести на clangd (где это возможно).
                        0

                        Тогда признаю вашу точку зрения на этот счет.
                        Хотя продолжу считать, что gcc -Wall -Werror -c -o /tmp/test.o $@; rm -f /tmp/test.o лучше запуска отдельного демона процедуры компиляции. (Хотя суть действия не меняется исключая конечно появление всех ошибок и предупреждений как ошибка на этапах до линковки.)

                0
                видимо очень сложно разделить функционал, как для java разработчиков.
                  0
                  А есть ли в этом смысл вообще? Неужели вариант с покупкой лицензии под коммерческую разработку и бесплатным использованием для pet проектов недостаточно выгодный?
                    0
                    Мне кажется этот вариант был бы очень крутой!
                    Как VS Community Edition, они и для коммерческой лицензии разрешают пользоваться, но очень небольшим компаниям.
                    Если бы у CLion была бы лицензия OpenSource — бесплатно, остальное платно — рынок был бы их полностью.
                      0
                      Все наши лецензии для Open Source бесплатные: www.jetbrains.com/buy/opensource
                        0
                        Спасибо, это известная информация.
                        Но там слишком много «если»…
                        Хотя компания может и не давать ничего, так что это в любом случае лучше чем ничего!

                        You have to be a project lead or a regular committer.
                        Your OS project meets the Open Source definition.
                        Your OS project may not offer paid sponsorship, or receive funding from commercial companies or organizations (NGO, education, research, or governmental). You may not provide any paid support, consulting or training services for your OS project, and you may not distribute paid versions of your OS software. Contributors who are paid to work on the project are not eligible.
                        Your OS project is in active development for a minimum of 3 months.
                        Your OS project's community is active.
                        You release updated builds on a regular basis.
                          0
                          «Если» много, но все они имеют причины. Если Вам кажется, что вы не до конца удовлетворяете условиям или не уверены в чем-то, но все равно хотели бы получить лицензию для разработки OS проекта, стоит написать на sales@jetbrains.com, мы попробуем разобраться с Вашим конкретным случаем в частном порядке.
                +1

                Появится ли когда-нибудь расширяемая плагинами модель проекта? Помимо цмейка есть множество не поддерживаемых вами билд систем и хотелось бы иметь возможность хотя бы самому дописать их поддержку для clion.

                  +1
                  CLion умеет не только CMake. Есть еще compilation database, которую можно сгенерировать из почти всего.

                  Но вопрос, конечно, разумный. И ответ — да, появится. Мы как раз в процессе выделения API. Надеюсь, в следующем году будет версия, которой можно будет пользоваться.
                    0
                    Есть еще compilation database

                    Compilation database, к сожалению, является лишь списком исходников с флагами и не располагает информацией о таргетах. Следовательно, для больших проектов совершенно не годится.


                    да, появится

                    Отличные новости! Спасибо =)

                  +2

                  У меня есть две основные претензии к CLion:


                  • Он так и не научился Ninja. Даже с CMake.
                  • В нем нет нормального хоткея переключиться .h/.cpp. Есть Go to Related symbol, который на больших проектах тормозит настолько, что быстрее ввести имя файла вручную...
                    +1
                    • Ninja — не умеем, есть технические причины, но планируем сделать (вероятно заработает, когда перейдем на CMake server). Просто руки не доходят.
                    • .h/.cpp переключение — тоже сделаем, надеюсь, уже в 19.1.
                      0

                      У меня в режиме Unix Makefiles сборка без изменений (по факту просто проверка что всё собрано) занимает около 5-7 секунд… С Ninja меньше секунды...

                        +1
                        С тем, что Ninja генератор быстрее Makefiles, мы не спорим. Это безусловно так. Сложности там именно в поддержки формата в CLion. Решаемые, но требуют доп.ресурсов, которые пока заняты другим.
                          0

                          Спасибо!

                      0
                      У меня в CLion это есть. Попробуйте:
                      1. Переключение h/cpp: ctrl+alt+home
                      2. Можно уйти в навигацию по дереву: alt+home

                      Это описано в key map reference.
                        +1
                        ctrl+alt+home — это и есть Go to Related Symbol. Но он действительно не всегда навигирует туда, куда хочется. В основном, потому что это платформенное действие, а надо реализовать именно действие со спецификой C++. Мы планируем это сделать. Именно в формате добавить отдельное действие навигации для переключения между заголовочным файлом и сорс.
                          +1

                          Go to related symbol делает именно то что в названии. Грубо говоря если курсор на обьявлении метода в хидере, то он перейдет в реализацию в соответствующем .cpp файле. Но если реализацию метода спрятать в абсолютно другом .cpp файле (с другим именем) то CLion его всё равно найдет там.


                          Это было бы не так важно, если бы не одно но. На больших проектах это очень медленно.

                        0
                        А удаленная отладка (под WSU в том числе) и т.д. работает и в Rust plugin?
                          0
                          Удаленная отладка, запуск, компиляция, которая по ssh — работает только с CMake. В Rust, полагаю, вы Cargo используете. Так что — пока нет.
                          0
                          А поддержки Ninja всё ещё нет?
                            0
                            Ну вот я выше ответила:
                            Ninja — не умеем, есть технические причины, но планируем сделать (вероятно заработает, когда перейдем на CMake server). Просто руки не доходят.
                            0
                            А поддержки Ninja всё ещё нет?
                              0
                              А я порадовался тому, что есть gradle c++ проекты, и оно всё быстро и из коробки завелось на виндовой машине, найдя локальную установку Visual Studio. Только жаль, что debug в нём не работает. Хотелось бы подвижек в этом направлении тоже, но, как я понимаю, тут ещё дело за самими gradle встало…
                                0
                                Отладчик для случая VS/MSVC планируется в следующем году. Мы его сами пишем, так как VS отладчик проприетарный.
                                  0

                                  Это что-то на базе cdb/windbg?

                                    +1
                                    Нет, такой вариант мы пробовали, там возникло много проблем.
                                    Сейчас делаем на базе LLDB.
                                0
                                Я смотрю приоритет отдался удалённой разработке, а как идут дела в вопросах удалённой отладки, удалённого профилирования и т.д.?
                                Есть локальная машина на которой идёт разработка, на ней все исходники, cmake, SDK целевой платформы. Целевая платформа это linux на ARM устройстве.
                                Проект собирается. Отлично. Проект можно руками перенести на целевую платформу, запустить под gdb сервером, создать конфигурацию удалённой отладки и ок, это в целом даже будет работать. Но это неудобно.
                                Хочется один раз настроить удалённую машину и получить синхронизацию. Собирать приложение сразу туда, запускать из среды разработки.
                                Может подобные сценарии будут рассматриваться в рамках вашей работы под Embedded?
                                Или ещё более сложные, например разработка под WSL и отладка на железе?
                                  0
                                  Не очень поняла, наверное, но WSL поддержан уже. Сборка/запуск из CLion сразу на удаленной машине — тоже. Отладка на железе — в планах, соб-но, про них и речь в конце.
                                    0
                                    Сейчас в CLion можно собраться и отладиться без проблем в рамках одной машины (локальной или удалённой). Это хорошо и здорово.
                                    Но когда надо собраться на одной машине, а отладиться на другой — надо сделать большое количество действий руками: перенести собранную программу, запустить gdb сервер, подключиться к серверу из Clion.
                                    Ошибка, падение,… — руками перезапускать gdb сервер. Изменение — руками переносить собранный файл.
                                    В моём случае железо это почти обычный Linux. Просто на ARM. С обычным ssh и прочими радостями жизни. Но ресурсов железа не хватит чтоб прям там собирать программу и пользоваться возможностью удалённой разработки. Нужна именно простая удалённая отладка. То есть грубо говоря rsync бинарника и запуск gdb сервера через ssh.
                                    И WSL мне нужен как среда разработки но не как среда отладки. Из WSL мне всё равно надо будет скопировать приложение на целевое устройство, запустить gdb сервер и далее по пунктам.
                                      0
                                      А, поняла, спасибо! Это CPP-7050. Мы его планируем в следующем году сделать.
                                  0
                                  Когда уже будет нормальная поддержка для Unreal Engine 4? Очень хочу уйти со студии (Любитель Rider, WebStorm, Intellij idea)
                                    0
                                    А что именно хочется?
                                    Сейчас два пути развития — есть CLion и есть возможность получить CMake проект прямо из UE4 редактора, там с 4.20 CLion/CMake генерация проекта есть встроенная. В CLion дальше есть прикольный плагин для комплишена рефлекшен спецификаторов.
                                    Ну и мы планируем в Rider иметь специальную поддержку для C++/Unreal Engine случая, тулчейн MSVC/msbuild.
                                      0
                                      Вот как раз специализированный плагин для поддержки UE4 у меня и не работает… Встраивание поддержки с++ в Rider? Это конечно круто, но почему тогда CLion и Rider изначально не объединили, подобно Visual Studio? Я также много работаю на C# и мне очень нравится Rider. Пожалуй единственное, в чем он сейчас уступает студии — это удаленная отладка. Радует, что работы в направлении поддержки UE4 ведутся:)
                                        0
                                        А как именно не работает? fsmorygo наверное может помочь, он автор)
                                          0
                                          Касательно вопроса про CLion/Rider, там длинная история, но по факту CLion вообще скорее ориентирован на кросс-платофрменную разработку и никакой поддержки Windows специфики и msbuild/MSVC тулчейна в нем никогда не планировали, а вот в Rider все иначе — там как раз легко поддержать UE4 разработку, которая в основном именно в таком окружении происходит.

                                          Ну и про удаленную отладку в Rider: blog.jetbrains.com/dotnet/2018/11/29/remote-debugging-comes-rider-2018-3
                                            0
                                            Ну и про удаленную отладку в Rider...
                                            оО Крутяк! Спасибо
                                      0
                                      А можно поинтересоваться, чем определяется очередность исправления ошибок? Вот уже пять месяцев без движения висит CPP-13456, который намертво завешивает IDE.
                                        0
                                        Частотой воспроизведения случая, количеством репортов, сложностью фикса, планами по более глобальным переделкам каких-то подсистем связанных. Мы посмотрим, что там за проблема. Спасибо за напоминание.
                                        0
                                        Ребята, когда добавите нормальную поддержку IAR toolchain, не покупаем только из-за кривой поддержки кроссплатформенных компиляторов, таких как IAR.
                                          0
                                          IAR toolchain сейчас не поддержан, так как не GCC-based. Но планируем его в рамках всяческих задач по embedded поддержке. Вероятно, в 2019.x каком-нибудь. Вот тут можно подписаться на обновления по задаче.
                                            0

                                            Спасибо, будет ждать.

                                              0
                                              2019.1 вышел на пробу, а так ничего и не поправлено. include_directories как не работал, так и не работает. Не могу пользоваться :(, уже бы 10 лицензий купили бы. А так только 2 попробовать и ждем…
                                                0
                                                Что значет include_directories не работает, поясните? Можно тикет дать в трекере.
                                                  0
                                                  Изначально вот этот:
                                                  CPP-10954
                                                  и
                                                  CPP-12576
                                                  вроде как ошибку компиляции убрали, но include_directories все равно игнорируется.
                                                  Ну и связанный с ним:
                                                  CPP-12788
                                                  При поддержку IAR тут:
                                                  CPP-1492

                                          Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                                          Самое читаемое