На днях мы выпустили CLion 2018.3. Третий в этом году крупный релиз подытоживает нашу работу по двум важным направлениям развития — улучшению языковой поддержки и удаленной разработке.
Кроме того, мы, наконец:
- добавили средства профилирования кода;
- переделали команды в редакторе для сборки/пересборки кода на уровне одного файла, нескольких таргетов или всего проекта целиком;
- вместе с другими IDE на базе платформы IntelliJ добавили поддержку Git submodules и GitHub pull requests;
- улучшили средства универсального доступа к возможностям IDE (accessibility).
Подробнее об этих и других нововведениях читайте ниже. А чтобы попробовать новые возможности и улучшения, скачивайте бесплатную 30-дневную версию с нашего сайта.
Поддержка языка C++
Больше С++17
Парсер CLion научился понимать две новые возможности стандарта C++17 — fold expressions и deduction guides. С одной стороны, изменения в парсере — это еще не полная поддержка, но, как минимум, подсветка кода будет более правильная, а для случаев user-defined deduction guides IDE даже правильно выведет тип и его можно будет увидеть, например, при вызове информации о параметрах функции.
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:
То есть можно независимо включать/выключать необходимую функциональность поверх 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.
Настроить такую удаленную конфигурацию очень легко — надо просто создать удаленный тулчейн в 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).
Подробно о том, что необходимо установить на компьютер, чтобы заработало профилирование кода, читайте в блоге или онлайн-документации.
Стоит отметить, что UI/UX пока несколько экспериментальный. Его планируется существенно улучшать в версиях 2019.x. Но уже есть полезные штуки, вроде возможности посмотреть все треды вместе или по одному, возможность навигации на исходный код и др.
Команды сборки и пересборки кода
Количество разнообразных комбинаций команд сборки так выросло, что мы решили вынести их все в отдельный пункт меню — Build. Там и сборка/пересборка всего проекта, и таргета
all из всех или из выбранного CMake профайла, и выбранной конфигурации, и одного конкретного файла:
Это, понятное дело, для CMake. Для compilation database там будет только команда пересборки конкретного файла.
Универсальные диалоги: Run Anything и Search Everywhere
С диалогом Search Everywhere (
Double Shift) пользователи CLion знакомы давно, как и с диалогом Find Action (Ctrl+Shift+A / ??A) для поиска команды или настройки по имени, и с диалогами навигации на файл, символ или класс по их имени. И вот теперь это, на самом деле, один и тот же диалог!
Отдельные диалоги превратились в отдельные вкладки, переключение работает через
Tab. Заодно мы устранили ряд проблем, связанных с этими диалогами, в т. ч. потери фокуса и некорректные размеры.Другой новый универсальный диалог — Run Anything (
Double Ctrl). Из него можно запустить приложение в обычном режиме или из-под отладчика, а также открыть любой проект:
Проверки в сompilation_database.json
Compilation database — альтернативная проектная модель, которую уже некоторое время поддерживает CLion. Она очень удобна тем, что получить ее можно фактически из любой другой проектной модели, популярной или вообще кастомной. CLion умеет открывать проекты из compilation database, парсить правильно код и предоставлять все умные средства работы с кодом. Единственный минус — это отсутствие в данном формате информации о сборке всего проекта, так что собрать из IDE пока получится только отдельные файлы.
В этом релизе мы добавили в CLion схему для файлов сompilation_database.json, а на основе уже этой схемы реализовали проверки в самом файле. Например, некорректный тип значения проперти или вообще отсутствующая проперть:
Проверки могут быть очень полезны, если вы-таки решили написать такой файл руками или подправить имеющийся файл.
Производительность редактора и тесты
Во многих дампах от наших пользователей было видно, что существенные проблемы с производительностью IDE связаны с тем, как IDE определяет список имеющихся в проекте тестов. В версии 2018.3 мы сделали этот процесс ленивым, и теперь, если вы не открыли ни одного файла с тестами в редакторе, они не будут индексироваться. Кроме того, были произведены улучшения производительности при навигации на результаты тестов, автодополнении тестовых макросов и пр.
Улучшения в редакторе
Как известно, в окне Quick Documentation (
Ctrl+Q / F1) CLion умеет показывать не только документацию и комментарии к коду, но и выведенные типы для переменных и финальную подстановку в макросах. Эта финальная подстановка теперь отформатирована, и в ней подсвечиваются ключевые слова. Очень удобно для сложных макросов с несколькими уровнями вложения, например для Boost:
Комментарии TODO теперь можно делать многострочными, главное соблюсти отступ для второй и последующих строк — CLion автоматически поймет, что это часть комментария TODO:
Есть пользователи, для которых стандартные темы не удобны, так как не обладают достаточной контрастностью. Для них мы добавили специальную High-contrast Theme. Ее можно включить только в редакторе кода (Ctrl+`) или же для всей IDE (Settings/Preferences | Appearance & Behavior | Appearance | Theme).
Вместе с 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
Комментарии (50)
Filippok
28.11.2018 18:52+2Появится ли когда-нибудь расширяемая плагинами модель проекта? Помимо цмейка есть множество не поддерживаемых вами билд систем и хотелось бы иметь возможность хотя бы самому дописать их поддержку для clion.
anastasiak2512 Автор
29.11.2018 01:17CLion умеет не только CMake. Есть еще compilation database, которую можно сгенерировать из почти всего.
Но вопрос, конечно, разумный. И ответ — да, появится. Мы как раз в процессе выделения API. Надеюсь, в следующем году будет версия, которой можно будет пользоваться.Filippok
29.11.2018 15:09Есть еще compilation database
Compilation database, к сожалению, является лишь списком исходников с флагами и не располагает информацией о таргетах. Следовательно, для больших проектов совершенно не годится.
да, появится
Отличные новости! Спасибо =)
dion
28.11.2018 19:25+2У меня есть две основные претензии к CLion:
- Он так и не научился Ninja. Даже с CMake.
- В нем нет нормального хоткея переключиться .h/.cpp. Есть Go to Related symbol, который на больших проектах тормозит настолько, что быстрее ввести имя файла вручную...
anastasiak2512 Автор
29.11.2018 01:19- Ninja — не умеем, есть технические причины, но планируем сделать (вероятно заработает, когда перейдем на CMake server). Просто руки не доходят.
- .h/.cpp переключение — тоже сделаем, надеюсь, уже в 19.1.
dion
29.11.2018 12:26У меня в режиме Unix Makefiles сборка без изменений (по факту просто проверка что всё собрано) занимает около 5-7 секунд… С Ninja меньше секунды...
anastasiak2512 Автор
29.11.2018 12:58+1С тем, что Ninja генератор быстрее Makefiles, мы не спорим. Это безусловно так. Сложности там именно в поддержки формата в CLion. Решаемые, но требуют доп.ресурсов, которые пока заняты другим.
Brotherofken
29.11.2018 11:57У меня в CLion это есть. Попробуйте:
- Переключение h/cpp: ctrl+alt+home
- Можно уйти в навигацию по дереву: alt+home
Это описано в key map reference.anastasiak2512 Автор
29.11.2018 12:02ctrl+alt+home — это и есть Go to Related Symbol. Но он действительно не всегда навигирует туда, куда хочется. В основном, потому что это платформенное действие, а надо реализовать именно действие со спецификой C++. Мы планируем это сделать. Именно в формате добавить отдельное действие навигации для переключения между заголовочным файлом и сорс.
dion
29.11.2018 12:25Go to related symbol делает именно то что в названии. Грубо говоря если курсор на обьявлении метода в хидере, то он перейдет в реализацию в соответствующем .cpp файле. Но если реализацию метода спрятать в абсолютно другом .cpp файле (с другим именем) то CLion его всё равно найдет там.
Это было бы не так важно, если бы не одно но. На больших проектах это очень медленно.
ijsgaus
29.11.2018 00:49А удаленная отладка (под WSU в том числе) и т.д. работает и в Rust plugin?
anastasiak2512 Автор
29.11.2018 01:21Удаленная отладка, запуск, компиляция, которая по ssh — работает только с CMake. В Rust, полагаю, вы Cargo используете. Так что — пока нет.
SemmZemm
29.11.2018 01:21А поддержки Ninja всё ещё нет?
anastasiak2512 Автор
29.11.2018 01:21Ну вот я выше ответила:
Ninja — не умеем, есть технические причины, но планируем сделать (вероятно заработает, когда перейдем на CMake server). Просто руки не доходят.
SimSonic
29.11.2018 08:50А я порадовался тому, что есть gradle c++ проекты, и оно всё быстро и из коробки завелось на виндовой машине, найдя локальную установку Visual Studio. Только жаль, что debug в нём не работает. Хотелось бы подвижек в этом направлении тоже, но, как я понимаю, тут ещё дело за самими gradle встало…
anastasiak2512 Автор
29.11.2018 11:46Отладчик для случая VS/MSVC планируется в следующем году. Мы его сами пишем, так как VS отладчик проприетарный.
dion
29.11.2018 12:28Это что-то на базе cdb/windbg?
anastasiak2512 Автор
29.11.2018 12:59+1Нет, такой вариант мы пробовали, там возникло много проблем.
Сейчас делаем на базе LLDB.
MadHacker
29.11.2018 12:54Я смотрю приоритет отдался удалённой разработке, а как идут дела в вопросах удалённой отладки, удалённого профилирования и т.д.?
Есть локальная машина на которой идёт разработка, на ней все исходники, cmake, SDK целевой платформы. Целевая платформа это linux на ARM устройстве.
Проект собирается. Отлично. Проект можно руками перенести на целевую платформу, запустить под gdb сервером, создать конфигурацию удалённой отладки и ок, это в целом даже будет работать. Но это неудобно.
Хочется один раз настроить удалённую машину и получить синхронизацию. Собирать приложение сразу туда, запускать из среды разработки.
Может подобные сценарии будут рассматриваться в рамках вашей работы под Embedded?
Или ещё более сложные, например разработка под WSL и отладка на железе?anastasiak2512 Автор
29.11.2018 13:00Не очень поняла, наверное, но WSL поддержан уже. Сборка/запуск из CLion сразу на удаленной машине — тоже. Отладка на железе — в планах, соб-но, про них и речь в конце.
MadHacker
29.11.2018 13:22Сейчас в CLion можно собраться и отладиться без проблем в рамках одной машины (локальной или удалённой). Это хорошо и здорово.
Но когда надо собраться на одной машине, а отладиться на другой — надо сделать большое количество действий руками: перенести собранную программу, запустить gdb сервер, подключиться к серверу из Clion.
Ошибка, падение,… — руками перезапускать gdb сервер. Изменение — руками переносить собранный файл.
В моём случае железо это почти обычный Linux. Просто на ARM. С обычным ssh и прочими радостями жизни. Но ресурсов железа не хватит чтоб прям там собирать программу и пользоваться возможностью удалённой разработки. Нужна именно простая удалённая отладка. То есть грубо говоря rsync бинарника и запуск gdb сервера через ssh.
И WSL мне нужен как среда разработки но не как среда отладки. Из WSL мне всё равно надо будет скопировать приложение на целевое устройство, запустить gdb сервер и далее по пунктам.anastasiak2512 Автор
29.11.2018 13:40А, поняла, спасибо! Это CPP-7050. Мы его планируем в следующем году сделать.
Xambey
29.11.2018 17:18Когда уже будет нормальная поддержка для Unreal Engine 4? Очень хочу уйти со студии (Любитель Rider, WebStorm, Intellij idea)
anastasiak2512 Автор
29.11.2018 17:20А что именно хочется?
Сейчас два пути развития — есть CLion и есть возможность получить CMake проект прямо из UE4 редактора, там с 4.20 CLion/CMake генерация проекта есть встроенная. В CLion дальше есть прикольный плагин для комплишена рефлекшен спецификаторов.
Ну и мы планируем в Rider иметь специальную поддержку для C++/Unreal Engine случая, тулчейн MSVC/msbuild.Xambey
29.11.2018 17:26Вот как раз специализированный плагин для поддержки UE4 у меня и не работает… Встраивание поддержки с++ в Rider? Это конечно круто, но почему тогда CLion и Rider изначально не объединили, подобно Visual Studio? Я также много работаю на C# и мне очень нравится Rider. Пожалуй единственное, в чем он сейчас уступает студии — это удаленная отладка. Радует, что работы в направлении поддержки UE4 ведутся:)
anastasiak2512 Автор
29.11.2018 18:20А как именно не работает? fsmorygo наверное может помочь, он автор)
anastasiak2512 Автор
29.11.2018 18:23Касательно вопроса про CLion/Rider, там длинная история, но по факту CLion вообще скорее ориентирован на кросс-платофрменную разработку и никакой поддержки Windows специфики и msbuild/MSVC тулчейна в нем никогда не планировали, а вот в Rider все иначе — там как раз легко поддержать UE4 разработку, которая в основном именно в таком окружении происходит.
Ну и про удаленную отладку в Rider: blog.jetbrains.com/dotnet/2018/11/29/remote-debugging-comes-rider-2018-3
mkshma
Ребяяяяяяят, ну дайте уже Community Edition пжлста.
anastasiak2512 Автор
Вынуждена разочаровать — пока таких планов у нас нет.
sborisov
Жаль конечно, но всё равно мы все очень любим ваши инструменты!!!
anastasiak2512 Автор
Спасибо за поддержку!
moscas
Для любых наших IDE есть вариант, как платить не ноль, но очень мало: сидите на ЕАПах, а в те месяцы, когда их нет – покупайте месячную подписку. Итого это выйдет примерно три (ну, окей, четыре) платных месяца в год. Получается, 48 долларов в год, то есть 250 рублей в месяц :) Точно так уж нужна комьюнити?
dion
Летом тут за те же ~45 баксов раздавали годичную лицензию.
moscas
Ну да, или скидки ловить.
Punk_Joker
Можно узнать причины?
anastasiak2512 Автор
Чтобы делать коммьюнити версию нужны веские причины и обстоятельства, мы их пока не видим в случае CLion/C++.
AntonAlekseevich
Планов нет или все-таки не решена бизнес-модель что продать из инструмента CLion.
Предлагаю убрать:
Ограничить: настройки как это сделано в Intelij IDEA и PyCharm (соответствующих редакций);
Это и будет Community Edition для CLion.
P. S. И никаких веских причин кроме экономических не надо. Будем честны перед потребителями.
Плюс с потребителей Community Edition берите деньгу за техподдержку и доступ к специальному репозиторию необходимого функционала.
anastasiak2512 Автор
Мы не берем деньги за техподдержку принципиально. А без того же clangd поддержка языка очень страдает. В общем, спасибо за предложение, но пока кажется, что это не релевантно.
AntonAlekseevich
Рад, что JetBrains принципиальна.
Для комьюнити версии нейтрализация clangd не вызовет особых страданий у потребителей ведь не всегда им нужен code completion. (Да, я отчасти не всегда на стороне потребителя.)
Оно окажет отклик лишь после тестового введения комьюнити версии с опросом пользователей.
anastasiak2512 Автор
Я не соглашусь про clangd — он сейчас используется для показа ошибок и предупреждений, и сильно помогает особенно в случае использования фич языковых, которые не поддерживает наш собственной движок пока. Ну и мы в целом планируем попробовать довольно много фич в будущем перевести на clangd (где это возможно).
AntonAlekseevich
Тогда признаю вашу точку зрения на этот счет.
Хотя продолжу считать, что
gcc -Wall -Werror -c -o /tmp/test.o $@; rm -f /tmp/test.oлучше запуска отдельного демона процедуры компиляции. (Хотя суть действия не меняется исключая конечно появление всех ошибок и предупреждений как ошибка на этапах до линковки.)sborisov
видимо очень сложно разделить функционал, как для java разработчиков.
mkshma
А есть ли в этом смысл вообще? Неужели вариант с покупкой лицензии под коммерческую разработку и бесплатным использованием для pet проектов недостаточно выгодный?
sborisov
Мне кажется этот вариант был бы очень крутой!
Как VS Community Edition, они и для коммерческой лицензии разрешают пользоваться, но очень небольшим компаниям.
Если бы у CLion была бы лицензия OpenSource — бесплатно, остальное платно — рынок был бы их полностью.
anastasiak2512 Автор
Все наши лецензии для Open Source бесплатные: www.jetbrains.com/buy/opensource
sborisov
Спасибо, это известная информация.
Но там слишком много «если»…
Хотя компания может и не давать ничего, так что это в любом случае лучше чем ничего!
anastasiak2512 Автор
«Если» много, но все они имеют причины. Если Вам кажется, что вы не до конца удовлетворяете условиям или не уверены в чем-то, но все равно хотели бы получить лицензию для разработки OS проекта, стоит написать на sales@jetbrains.com, мы попробуем разобраться с Вашим конкретным случаем в частном порядке.