Лето за окном пролетает для нас почти незаметно, потому что все эти месяцы мы посвятили работе над новым релизом 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
Комментарии (60)
MooNDeaR
25.07.2019 15:39-1Подсказки для аргументов работаю из ряда вон плохо. Особенно для шаблонных классов. Особенно с наследованием и лямбдами в качестве параметров. А иногда и вообще просто отказывается показывать эти подсказки. Проект большой и сложный, но в целом всё корректно написано, должно бы работать.
Плюс, хотелось бы кастомизации с какой стороны от переменной отображать подсказку. Я бы хотел иметь возможность видеть их с правой стороны, чтобы форматирование вот такого кода не плыло:
object->method( true, false, 100, {} );
P.S.
Всё еще нет при отладке в окошке для переменных кнопки "показать значение ОДНОЙ переменной в HEX". Как переключить все и сразу мне известно, но мне нужно ТОЛЬКО одну переменную. Шел 2019-й...
anastasiak2512 Автор
25.07.2019 15:45+1Давайте разбираться по очереди.
Про подсказки. А можно в трекер сразу примеров, где не работает? Мы посмотрим и обязательно починим.
Про кастомизацию — как-то традиционно во всех языках эти подсказки слева. Но опять же рекомендую вам тикет в трекере завести. Если запрос окажется важен и другим пользователям, то мы обязательно его рассмотрим.
Про Hex. Именно только одной? Почему всех сразу плохо (там же и hex, и обычная запись рядом показываются в таком случае)? Поясните, пожалуйста.MooNDeaR
25.07.2019 21:21А можно в трекер сразу примеров, где не работает?
Не можно. NDA как-никак. Воспроизвести на маленьком объеме кода не получается, а разбираться что-там сломалось на большом проекте не очень как-то хочется.
Про кастомизацию — как-то традиционно во всех языках эти подсказки слева. Но опять же рекомендую вам тикет в трекере завести. Если запрос окажется важен и другим пользователям, то мы обязательно его рассмотрим.Заведу вечерком.
там же и hex, и обычная запись рядом показываются в таком случае
Что-то я не замечал вывод обычной записи. Мб смотрел куда-то не туда. Приду домой проверю.
anastasiak2512 Автор
26.07.2019 00:11Выглядит вот так https://www.jetbrains.com/help/clion/using-hexadecimal-view.html
slonopotamus
25.07.2019 20:22Традиционный вопрос, с UE4 уже наконец полноценно работает? :)
anastasiak2512 Автор
25.07.2019 20:28Мы не планируем уделять повышенное внимание UE4 разработке в CLion, по-крайней мере, в ближайшее время.
Особый упор на UE4 разработку, с перфоманс-оптимизациями для UE4 кода и специальными фичами (например, понимание UE4 naming правил, понимание макросов рефлексии и спецификаторов, и пр.) делается в ReSharper C++ (плагин для VS) + (по секрету) мы планируем добавить UE4 поддержку в Rider (то есть C++ с msbuild/msvc как в ReSharper C++). Именно Rider будет такой gamedev IDE для Unity & UE4, в каком-то смысле.slonopotamus
25.07.2019 23:46Resharper — хорошо, но не прекрасно, т.к. win-only, в отличие от CLion. Ну и вообще, если честно, необходимость обвешивать IDE за $500 (или сколько там сейчас VS Pro стоит) сверху ещё и плагинами, чтобы получить удобное для работы окружение, вызывает у моей жабы приступы жадности. Хоть деньги и не мои, а работодателя, бюджет всегда имеет ограничения и если для повышения эффективности разработки куплено что-то одно, значит не куплено что-то другое.
anastasiak2512 Автор
26.07.2019 00:12Поэтому будет Rider c UE4 поддержкой ;)
BlinCT
26.07.2019 11:31А могли бы написать причину почему вы именно хотите сосредаточится на работе UE4 в Rider а не в CLion? Просто пытаюсь понять. Я пишу крестовый код в CLion и все там делаю, а теперь получается что работать с крестовым проектом UE4 мне надо и Rider брать и только из за этого). Я надеюсь вы понимаете о чем я)
anastasiak2512 Автор
26.07.2019 11:41История такая — Rider С++ и CLion предполагают совершенно разный таргетинг. Game dev разработка она дольно сильно Windows-specific, там много msbuilt. В этой области у нас есть такие тулы как ReSharper / ReSharper C++. Конечно, с приходом .NET Core в опер сорс и на другие платформы, стал вопрос тулинга для него на других плфтормах — и Rider как раз покрывает эти случаи, ибо кросс-платформенный.
Но по части Unreal Engine — там 95% разработки (по данным самих Epic Games) это desktop/console/Windows dev. Тут ReSharper C++/Rider просто ближе лежат.
К тому же, в Rider уже есть продвинутая поддержка Unity. И хочется, наверное, два основных движка из GameDev покрыть одной IDE. Так как полно студий, которые используют и то, и другое.
CLion в свою очередь ориентируется именно на кросс-платформенную C++ разработку, особенно на финансы/банкинг/трейдинг, AI, embedded (новое для нас направление), и прочее. И хотя в CLion сейчас есть поддержка и MSVC, и даже экспериментальный отладчик для него, вряд ли мы будем углубляться в специфику Windows платформы в CLion, а тем более в специфику UE4.BlinCT
26.07.2019 11:52Ну я в принципе вас понял. Просто я свой проект на UE4 пишу именно на линукс. И как то даже в мыслях нету что мне надо на мелкомягкой с ним работать если у меня на линуксе все работает. И я уже молчу про то как пошла вверх производительность Вулкана и его применение в UE4. А по поводу данных самих же Epic Games то они темнят очень сильно. Это больше на лож похоже чем правду. Они этим оправдывают отсутствие их магазина под линукс. И само собою даже на их движке игар если кросплатформенная то пойдет в Steam а не к ним.
anastasiak2512 Автор
26.07.2019 11:56В целом, для UE4 есть план поддержать в Rider C++ не .sln файлы, а именно напрямую .uproject. Тогда мы сможем все это кросс-платформенно запускать. И напрямую через UBT собирать, отвязавшись от студии вообще. Но это пока очень далекие планы)
BlinCT
26.07.2019 13:19Главное чтобы это все не мешало открывать проекты в cmake и компилить это все как из IDE так и из консоли. Так как открывая такой проектник он понятен, все на своих местах и ясно что и куда можно свое добавить, но когда открываешь эти… .sln и .uproject то это какой то ужас. Собрание какого то треша.
anastasiak2512 Автор
26.07.2019 13:22Не, как раз идея, что нативная проектная модель для UE4 — это .uproject. Все остальное же просто генерируется из uproject, причем генератор для CMake довольно странный и его бы улучшать и улучшать. Причем сами Epic-и легко ломают все эти генераторы, они их мало волнуют.
BlinCT
26.07.2019 13:32Вообще тут я согласен с вами. То что гинерируется cmake он такой ужасный, я бы руками лучше написал, с меньшим колличеством строк и можно было бы прочитать. Я на самом деле хотел написать на форуме и спросить зачем они такое усложнение делают для генерации, тот же CLion это при открытии нового проекта генерирует чище. Но понял что им навернео плевать. Ситуация была когда я им на форуме писал и предлагал вариант для их Launcher чтобы они под лиунксом сделали и под все дистрибы могли запускать, сам просто тестовый проект у себя сделал и все работает. А они даже не отреагировали на мое предложение. Обидненько…
anastasiak2512 Автор
26.07.2019 14:28Генератор CMake написан частично с нашей помощью, частично с помощью разработчика из Канадской студии, которому это было интересно. Epic-и к пул реквесту почти оотношения не имели. Разве что мы их попросили посмотреть.
Написать там лучше — тяжело, к сожалению. Надо как-то CLion-у объяснить, где сам движок, чтобы он его проиндексировал. Но в целом, там еще целое поле непаханное для улучшений. Но у нас нет на это ресурсов.
Они сами, как я понимаю, в основном все из командной строки делают, запускают generate.sh там скрипт в сорсах (или как он точно зовется). Знаю одного человека там, который на Linux в CLion с CMake работает)
BlinCT
26.07.2019 13:52Я правильно понимаю что для UE4 будет и плагин чтобы крестовый код в Rider открывать стабильно?
anastasiak2512 Автор
26.07.2019 14:30План добавить в Rider поддержку С++ (сейчас самый простой вариант — это под протоколу Rider-а подключить ReSharper C++ движок). А так же сделать SourceCode Access плагин для Unreal Editor, чтобы оттуда запускался Rider сразу.
gudvinr
25.07.2019 22:16Есть проблема: при использовании CLion для разработки, во время компиляции большого проекта вне IDE сама среда просто встаёт колом: ввод не работает, прокрутка не работает, меню не открываются. Не тормозит, а просто перестаёт отвечать какое-то время.
Проект использует cmake, оперативной памяти хватает, процессор естественно загружен, но другие приложения в этот момент отзывчивости не теряют вообще.
С чем, на ваш взгляд, такое поведение может быть связано и как можно исправить? Вещь исключительно специфичная для CLion, как я уже сказал — на другие приложения не распространяется и если, например, использую vscode с настроенным cmake tools, то тоже фризов нет вообще.
0xd34df00d
25.07.2019 23:22Аналогичная проблема. Заметил, что если запускать другие сборки с nice типа 10 или 19, то ничего колом не встаёт.
anastasiak2512 Автор
26.07.2019 00:15Если это именно фриз IDE, то в директории с логами должен быть thread dump автоматический. Посмотреть бы на него. Была когда-то похожая жалоба, но без каких-то дампов/логов мы разобраться не смогли. Если сможете дампы найти, приложите к запросу этому, пожалуйста, мы обязательно посмотрим, в чем там дело.
apro
26.07.2019 20:16С чем, на ваш взгляд, такое поведение может быть связано и как можно исправить?
У меня была похожая ситуация. Оказалось дело в GC, Java GC если точнее.
После серии мега фризов сама IDE предложила увеличить макс. размер
используемой памяти для jvm и все не то чтобы залетало, но подвисание UI исчезло.gudvinr
26.07.2019 20:24У меня под clangd выделено 8Гб + MaxHeap для Java тоже 8Гб установлен. Не сказал бы что что-то изменилось когда в своё время поднял показатели, да и два инстанса CLion занимают до 10Гб в сумме.
Juster
26.07.2019 10:53Отлично, спасибо за шикарные новости (особенно про отладчик msvc)!
Пара небольших идей:
1) Могли бы вы, пожалуйста, запилить показ значений переменных из cmake, например, при наведении курсора на ней? Было бы очень удобно, и сделать вроде бы несложно, т.к. они лежат в cmake кэше.
2) Когда на windows я делаю Install проекта, то всегда сталкиваюсь с досадой от того, что требуются права админа на запись в program files, приходится перезапускать clion. Было бы здорово автоматически запрашивать их повышение.
3) Swap двух строк через ctrl+shift+up/down очень часто выдаёт совершенно неожиданный результат. Я хочу просто поменять две строки местами, но, как правило, у автоформаттера на это свои планы. В результате я своппером не могу пользоваться.
Спасибо!anastasiak2512 Автор
26.07.2019 11:51Спасибо!
1) Могли бы вы, пожалуйста, запилить показ значений переменных из cmake, например, при наведении курсора на ней? Было бы очень удобно, и сделать вроде бы несложно, т.к. они лежат в cmake кэше.
Только CMake Cache или вообще переменных? (в общем случае, попахивает отладчиком, и кстати такие попытки были, есть даже 3rd party плагин для старых версий CMake). Я вот тут завела реквест, но наверное хорошо бы случаи использования поподробнее там описать.
2) Когда на windows я делаю Install проекта, то всегда сталкиваюсь с досадой от того, что требуются права админа на запись в program files, приходится перезапускать clion. Было бы здорово автоматически запрашивать их повышение.
Завинула в реквест
3) Swap двух строк через ctrl+shift+up/down очень часто выдаёт совершенно неожиданный результат. Я хочу просто поменять две строки местами, но, как правило, у автоформаттера на это свои планы. В результате я своппером не могу пользоваться.
Хорошо бы пример. Можно сразу в трекер.
Но в целом, автоформатирование используется во многих действиях в CLion. Следует, наверное, настроить правила форматера так, как вам надо, и тогда проблем не будет.BlinCT
26.07.2019 13:34По поводу install и на лиунксе надо) та же проблема, приходится перезапускать.
abusalimov
26.07.2019 16:503) Swap двух строк через ctrl+shift+up/down очень часто выдаёт совершенно неожиданный результат. Я хочу просто поменять две строки местами, но, как правило, у автоформаттера на это свои планы. В результате я своппером не могу пользоваться.
Я в таких случайх использую Alt+Shift+Up/Down, это простое перемещение строк без учета семантики конструкций и без вызова форматтера. Попробуйте, может, найдёте использование этих экшнов для себя более удобным, например, в сочетании с Expand/Shrink Selection перед перемещением строк.
a1ien_n3t
26.07.2019 11:34Вопросище. Почему так сложно и непонятна и не интуитивно настраивается удаленная отладка и деплой.
Собственно если сравнивать с qt creator.
Основная притензия я так и не понял как задеплоить и автоматом запустить под gdbserver'ом приложение.
Есть arm с linux, приложение собирается, задеплоить тоже вродее более менее понятно, но вот чтобы запустить отладку предлагается запускать вручную gdbserver на этом арме. Хотя уже есть настроеный ssh и ide моглабы сама это сделать.
Почему нельзя как в qt creator нажать кнопку run debug и ide сама убъет если запущенно приложение + возможность добавить кстомные скрипты(например перемонтировать файловую систему или еще что). Задеплоит новую верси. Сама стартанет gdbserver и подключится к нему.anastasiak2512 Автор
26.07.2019 11:52Так можно же! Для этого и сделана новая Embedded GDB Server конфигурация. Почитайте в посте.
a1ien_n3t
26.07.2019 12:05Нет, это не то. Это когда совсем малый арм и мы по openoncd подключаемся.
Я говорю когда удаленная отладка на большом арм с линуксом.
Тоесть на другом конце у нас полноценный линукс с ssh и вот хочется чтобы ide залезала туда по ssh убивала инстансы деплоила приложение и запускала там gdbserver(обычнй) и подключалась к ниму.anastasiak2512 Автор
26.07.2019 12:41А, я поняла, в чем разница.
Смотрите, какие есть сейчас варианты:
- Локальная embedded отдалдка через gdbserver, который CLion запустит сам, через новые конфигурации
- Remote GDB режим, но gdbserver надо запускать вручную (но мы планируем научить CLion его запускать самостоятельно — задача сейчас в разработке)
- Полноценный remote режим, но это не то, что вам сейчас нужно совсем
В принципе, в этой embedded GDB server конфигурации можно немного подкрутить, чтобы работать с ней через удаленное соединение. Просто вместо локального gdbserver-а надо указать скрипт, который пойдет по ssh и запустит gdbserver на другой стороне. Elmot может помочь с деталями. Высока вероятность, что оно заработает.
Ну и надеюсь, что в 2019.3 мы таки закончим с CPP-7050, которую я упоминала раньше.
rwscar
26.07.2019 11:52Кстати, CLion стал как будто бы шустрее работать, иногда кажется, что даже быстрее MSVS(вынужден использовать на работе).
К сожалению, экспериментальный отладчик у меня не взлетел: то ли он падает вместе с отлаживаемым процессом на дефолтном «hello world», то ли просто отладка отваливается (срабатывает бряк, начинаю изучать стек, через секунду в статус-баре вижу process finished и отладка заканчивается), ну да ничего, на то он и экспериментальный.anastasiak2512 Автор
26.07.2019 11:54Не, ну он не настолько экпериментальный) Все же у нас он много, где работает, и довольно стабильно. А можно попросить вас создать запрос в трекере и приложить туда логи IDE с доп. информацией из отладчика. Как ее собрать, описано тут.
BlinCT
26.07.2019 13:24Скажите, я понимаю что было в планах в начале добавить Makefile и уже потом остальные. Но вопрос конкретно более лучшей работы с Qt, то есть даже сам а работа с qmake не важна как работа с макросами, сигналами, слотами, дефайнами, дебагинг(на данный момент нельзя увидеть Qt обьекты, пример QString), то есть те вещи которые касаются именно Qt но как я понимаю отношения к API Project model не имеют. Сейчас у нас несколько программистов, пишим все в CLion а дебажить приходится Qt Creator открывать, или если надо из того же Q_PROPERTY сгенерировать методы(слоты и сигналы). Этот вопрос очень сильно волнует.
anastasiak2512 Автор
26.07.2019 13:31У Qt есть pretty printers, которые можно просто взять и заиспользовать в CLion. Передайте их через .gdbinit, который в home директории, и все будет работать.
gudvinr
26.07.2019 17:35А поддержка
.gdbinitв директории проекта есть?
Пихать проектозависимые пути/параметры в корневой конфиг — это ну такое себе.
В связанном с этим случае сегодня заметил, что запуская GDB через "Attach to process" он своей рабочей директорией считает не корень проекта, а
$HOMEи поменять это никак нельзя из настроек. Запуск в домашней директории и локальный.gdbinitрешили бы некоторое количество проблем и устранили дикий костыль в виде использования глобального конфига.
darkAlert
26.07.2019 13:54А умеет ли CLion из коробки работать со всякими андроид студиями и т.п.? Как Qt?
anastasiak2512 Автор
26.07.2019 14:31Что значит работать с Android Studio? Это же отдельная IDE, на базе IntelliJ-платформы, мало того с C++ поддержкой из CLion)
maxood
26.07.2019 14:46CLion — один из немногих продуктов, которые мне приятно использовать. Но некоторые вещи просто бесят! Исправьте баг youtrack.jetbrains.com/issue/CPP-15774!!!
anastasiak2512 Автор
26.07.2019 14:54Я так понимаю, что не работает в случае дефолтового значения для cmake.parallel.generation опции. Так?
Боюсь, что без примера для воспроизведения будет очень сложно поправить. Мы сами такое не наблюдаем, а в логах ничего подозрительного нет. Но мы попробуем еще раз глянуть.maxood
26.07.2019 15:10Я так понимаю, что не работает в случае дефолтового значения для cmake.parallel.generation опции. Так?
Так.
Но я ж не могу отправить вам мой проект для тестирования!
А делать некую симуляцию я тоже не могу (не хочу), мне за это не заплатят, а я вам плачу, между прочим :)maxood
26.07.2019 19:04Крайне интересно, этот «минусатор» сколько создал баг-репортов, сколько времени потратил на бесплатное тестирование коммерческих приложений, сколько накоммител в open-source проекты?
anastasiak2512 Автор
26.07.2019 19:08С одной стороны, вы правы. А с другой, если мы совсем никак не можем проблему воспроизвести, то поправить ее тоже очень тяжело. Особенно, если в логах ничего подозрительного и необычного нет вообще. Вот такая печальная история.
maxood
26.07.2019 19:17Так это вы были? Удивляюсь, ну да ладно. Я писал, как можно воспроизвести этот баг. Напишу еще раз — создайте CMake проект с использованием OpenMP и protobuf, например.
anastasiak2512 Автор
26.07.2019 19:21Обычно, все это не так просто. Ну то есть, мы наверное попробуем еще раз, конечно, но по опыту такие вещи так легко не удается воспроизвести.
HighPredator
26.07.2019 16:44Обновился.
Реализовали подсказки для аргументов вызова функций
Подсказки появляются не для всего. Сходу напоролся на два кейса на картинках.
anastasiak2512 Автор
26.07.2019 16:46Они действительно показываются не для всего, by design. А только там, где это реально необходимо / непонятно.
Подсказки показываются в тех случаях, когда действительно сложно понять, какие значения каким параметрам передаются, а именно, в случае использования в качестве аргументов вызова литералов или выражений более чем с одним операндом.
HighPredator
26.07.2019 17:00Хорошо, имитируем ситуацию: человек перепутал аргументы.
Имхо необходимость есть.anastasiak2512 Автор
26.07.2019 18:12Если человек переаутывает аргументы одного типа, есть отличный чек в анализаторе в CLion, который такое ловит: argument selection defect
Я при этом соглашусь, что странно показывать хинт перед nullptr и не показывать его перед NULL. Видимо такое откинулось по эвристикам. Завела тикет на это. Поправим.
Просто в целом, если расставить parameter hints везде, будет очень много шума. Но общая рекомендация — если вам кажется, что еще где-то они могут быть полезны, то создайте запрос в трекере с описанием примерам.
gudvinr
26.07.2019 17:38NULL— это вполне себе литерал, к примеру.anastasiak2512 Автор
26.07.2019 18:12да-да, я ответила выше. В кратце, завела багу) Перед nullptr он покажется при этом.
psinetron
Очень классно. Не планируется ли бесплатная версия CLion как Idea?
anastasiak2512 Автор
Community версии пока что в планах нет.
OnYourLips
Мои мысли на этот счет: community версия должна дополнять платную, а не конкурировать с ней. На примере python это можно увидеть: язык любим теми, кто не связан с профессиональной разработкой (но многие потенциально перейдут в неё), и бесплатная версия справляется с задачами таких людей, при этом рекламирует платную.