company_banner

Вышел CLion 2019.2: поддержка встроенной разработки, отладчик для MSVC, поиск неиспользованных заголовочных файлов

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

    Лето за окном пролетает для нас почти незаметно, потому что все эти месяцы мы посвятили работе над новым релизом 2019.2 нашей кросс-платформенной среды для разработки на C++ — CLion. Мы успели довольно много всего: и провести внутренний Хакатон, и попробовать новые идеи, и довести ряд исправлений и новых возможностей до непосредственного релиза. Но обо всем по порядку.

    CLion 2019.2 released

    Если коротко, то в этом релизе мы:

    • Продолжили дорабатывать поддержку разработки встроенных систем: появились новые возможности отладки и просмотр периферии.
    • Довели до приемлемого качества пока что экспериментальный отладчик для 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 и не только.

    Embedded configuration

    Достаточно создать и настроить соответствующую конфигурацию — указать путь до сервера GDB, аргументы, которые ему передать, возможно, какие-то более продвинутые настройки. Теперь запускайте отладку в данной конфигурации, и можно отлаживать на плате прямо из CLion!

    Есть одно важное ограничение, которое действует сейчас на обе конфигурации для отладки встроенных систем, — они обе пока что работают только с проектами на CMake. В будущем мы планируем добавить возможность запускать их для кастомных проектных моделей (CPP-16079).

    Для обеих существующих теперь конфигураций отладки встроенных систем (Embedded GDB Server и OpenOCD Download & Run) в новом релизе появилась возможность просмотра периферии при отладки. В целом, периферия специфицирована для устройств семейства ARM, в файлах формата .svd. Именно эти спецификации можно теперь подгрузить в CLion и просматривать выбранную периферию прямо в окне отладчика:

    Peripherals

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

    Экспериментальный отладчик для 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 доступен новый отладчик:

    MSVC toolchain

    В отладчике есть начальная поддержка нативных визуализаторов, как поставляемых со студией, так и пользовательских кастомных, найденных в проекте. Пока что возможность требует явного включения в настройках: Settings | Build, Execution, Deployment | Debugger Data Views | Enable NatVis renderers for LLDB. В одном из первых апдейтов мы планируем поправить несколько критических проблем с визуализаторами и тогда, вероятно, включить их по умолчанию.

    Natvis support

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

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


    Помимо нового экспериментального отладчика, мы провели ряд других улучшений:
    • Во встроенной консоли GDB/LLDB в окне отладчика в CLion теперь работает автодополнение команд самого отладчика (используйте Tab или Ctrl+Space).
    • Строковые точки останова теперь валидируются на лету, и их статус обновляется и показывается пользователю в виде соответствующей иконки. Самым интересным типом является Invalid, который был добавлен, чтобы идентифицировать те точки останова, которые не доступны в текущем исполняемом коде или для которых отсутствуют отладочные символы (в этом случае после их подгрузки статус точки останова автоматически обновится):
      Line breakpoints
    • При просмотре памяти в отладчике (Memory View) в новой версии появилась возможность перейти на произвольный адрес (по числовому адресу или имени/адресу переменной), а также представление памяти в формате ASCII:
      Memory View


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


    В этой области больших улучшений сразу несколько. Во-первых, мы полностью переписали проверку кода Unused Includes и включили ее по умолчанию. Раньше она тоже была, но давала большое количество ложных срабатываний, поэтому мы выключили ее по умолчанию. Почему же стало лучше? Мы полностью переписали проверку на базе второго дополнительного инструмента для парсинга кода, который, в свою очередь, основан на Clangd. Так что отсюда понятное ограничение — работать новая версия будет, только если Clangd у вас не отключен (по умолчанию он включен). Зато теперь в проверке на Unused Includes появилось несколько стратегий, между которыми можно выбирать:
    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) показывает документацию на опции и их значения, с примерами.
    • Добавлена проверка значений опций на допустимые.


    ClangFormat code assistance

    Подсказки для аргументов


    Что делать, если функция написана (возможно, не вами) так, что в качестве аргументов ей передается 3 целых числа? Как понять по вызову функции, что же значат передаваемые значения? Конечно, можно посмотреть сигнатуру функции в окне документации, перейти на определение функции или вызвать информацию о параметрах (Parameter Info). А если не делать этих явных действий?

    В версии CLion 2019.2 появились подсказки для аргументов — при вызове функции, лямбды, конструктора, списка инициализаций или при использовании макроса CLion показывает имена параметров перед переданными аргументами: Parameter hints
    Подсказки показываются в тех случаях, когда действительно сложно понять, какие значения каким параметрам передаются, а именно, в случае использования в качестве аргументов вызова литералов или выражений более чем с одним операндом. Подробнее в блогпосте.

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


    Конечно, нас часто спрашивают про улучшения производительности. Я повторюсь, для нас это наиболее приоритетная задача, но точечных изменений получается сделать не много, а глобальные требуют времени больше, чем 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, может быть полезна и простейшая подсветка:

    Ruby in CLion

    Часто в проектах на C++ встречаются разнообразные скрипты. Плагин для поддержки написания скриптов (Shell Script plugin) теперь встроен в CLion. Он обеспечивает не только подсветку кода, но и автодополнение и текстовое переименование:

    Shell Script

    Плагин для языка 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
    JetBrains
    120,83
    Делаем эффективные инструменты для разработчиков
    Поделиться публикацией

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

      +3
      Очень классно. Не планируется ли бесплатная версия CLion как Idea?
        0
        Community версии пока что в планах нет.
          0

          Мои мысли на этот счет: community версия должна дополнять платную, а не конкурировать с ней. На примере python это можно увидеть: язык любим теми, кто не связан с профессиональной разработкой (но многие потенциально перейдут в неё), и бесплатная версия справляется с задачами таких людей, при этом рекламирует платную.

        –3

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


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


        object->method(
            true,
            false,
            100,
            {}
        );

        P.S.
        Всё еще нет при отладке в окошке для переменных кнопки "показать значение ОДНОЙ переменной в HEX". Как переключить все и сразу мне известно, но мне нужно ТОЛЬКО одну переменную. Шел 2019-й...

          +3
          Давайте разбираться по очереди.

          Про подсказки. А можно в трекер сразу примеров, где не работает? Мы посмотрим и обязательно починим.

          Про кастомизацию — как-то традиционно во всех языках эти подсказки слева. Но опять же рекомендую вам тикет в трекере завести. Если запрос окажется важен и другим пользователям, то мы обязательно его рассмотрим.

          Про Hex. Именно только одной? Почему всех сразу плохо (там же и hex, и обычная запись рядом показываются в таком случае)? Поясните, пожалуйста.
            0
            А можно в трекер сразу примеров, где не работает?
            Не можно. NDA как-никак. Воспроизвести на маленьком объеме кода не получается, а разбираться что-там сломалось на большом проекте не очень как-то хочется.

            Про кастомизацию — как-то традиционно во всех языках эти подсказки слева. Но опять же рекомендую вам тикет в трекере завести. Если запрос окажется важен и другим пользователям, то мы обязательно его рассмотрим.

            Заведу вечерком.


            там же и hex, и обычная запись рядом показываются в таком случае

            Что-то я не замечал вывод обычной записи. Мб смотрел куда-то не туда. Приду домой проверю.

        0

        Традиционный вопрос, с UE4 уже наконец полноценно работает? :)

          0
          Мы не планируем уделять повышенное внимание UE4 разработке в CLion, по-крайней мере, в ближайшее время.
          Особый упор на UE4 разработку, с перфоманс-оптимизациями для UE4 кода и специальными фичами (например, понимание UE4 naming правил, понимание макросов рефлексии и спецификаторов, и пр.) делается в ReSharper C++ (плагин для VS) + (по секрету) мы планируем добавить UE4 поддержку в Rider (то есть C++ с msbuild/msvc как в ReSharper C++). Именно Rider будет такой gamedev IDE для Unity & UE4, в каком-то смысле.
            0

            Resharper — хорошо, но не прекрасно, т.к. win-only, в отличие от CLion. Ну и вообще, если честно, необходимость обвешивать IDE за $500 (или сколько там сейчас VS Pro стоит) сверху ещё и плагинами, чтобы получить удобное для работы окружение, вызывает у моей жабы приступы жадности. Хоть деньги и не мои, а работодателя, бюджет всегда имеет ограничения и если для повышения эффективности разработки куплено что-то одно, значит не куплено что-то другое.

              0
              Поэтому будет Rider c UE4 поддержкой ;)
                0
                А могли бы написать причину почему вы именно хотите сосредаточится на работе UE4 в Rider а не в CLion? Просто пытаюсь понять. Я пишу крестовый код в CLion и все там делаю, а теперь получается что работать с крестовым проектом UE4 мне надо и Rider брать и только из за этого). Я надеюсь вы понимаете о чем я)
                  0
                  История такая — 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.
                    0
                    Ну я в принципе вас понял. Просто я свой проект на UE4 пишу именно на линукс. И как то даже в мыслях нету что мне надо на мелкомягкой с ним работать если у меня на линуксе все работает. И я уже молчу про то как пошла вверх производительность Вулкана и его применение в UE4. А по поводу данных самих же Epic Games то они темнят очень сильно. Это больше на лож похоже чем правду. Они этим оправдывают отсутствие их магазина под линукс. И само собою даже на их движке игар если кросплатформенная то пойдет в Steam а не к ним.
                      0
                      В целом, для UE4 есть план поддержать в Rider C++ не .sln файлы, а именно напрямую .uproject. Тогда мы сможем все это кросс-платформенно запускать. И напрямую через UBT собирать, отвязавшись от студии вообще. Но это пока очень далекие планы)
                        0
                        Главное чтобы это все не мешало открывать проекты в cmake и компилить это все как из IDE так и из консоли. Так как открывая такой проектник он понятен, все на своих местах и ясно что и куда можно свое добавить, но когда открываешь эти… .sln и .uproject то это какой то ужас. Собрание какого то треша.
                          0
                          Не, как раз идея, что нативная проектная модель для UE4 — это .uproject. Все остальное же просто генерируется из uproject, причем генератор для CMake довольно странный и его бы улучшать и улучшать. Причем сами Epic-и легко ломают все эти генераторы, они их мало волнуют.
                            0
                            Вообще тут я согласен с вами. То что гинерируется cmake он такой ужасный, я бы руками лучше написал, с меньшим колличеством строк и можно было бы прочитать. Я на самом деле хотел написать на форуме и спросить зачем они такое усложнение делают для генерации, тот же CLion это при открытии нового проекта генерирует чище. Но понял что им навернео плевать. Ситуация была когда я им на форуме писал и предлагал вариант для их Launcher чтобы они под лиунксом сделали и под все дистрибы могли запускать, сам просто тестовый проект у себя сделал и все работает. А они даже не отреагировали на мое предложение. Обидненько…
                              0
                              Генератор CMake написан частично с нашей помощью, частично с помощью разработчика из Канадской студии, которому это было интересно. Epic-и к пул реквесту почти оотношения не имели. Разве что мы их попросили посмотреть.
                              Написать там лучше — тяжело, к сожалению. Надо как-то CLion-у объяснить, где сам движок, чтобы он его проиндексировал. Но в целом, там еще целое поле непаханное для улучшений. Но у нас нет на это ресурсов.
                              Они сами, как я понимаю, в основном все из командной строки делают, запускают generate.sh там скрипт в сорсах (или как он точно зовется). Знаю одного человека там, который на Linux в CLion с CMake работает)
                              0
                              Я правильно понимаю что для UE4 будет и плагин чтобы крестовый код в Rider открывать стабильно?
                                0
                                План добавить в Rider поддержку С++ (сейчас самый простой вариант — это под протоколу Rider-а подключить ReSharper C++ движок). А так же сделать SourceCode Access плагин для Unreal Editor, чтобы оттуда запускался Rider сразу.
            0

            Есть проблема: при использовании CLion для разработки, во время компиляции большого проекта вне IDE сама среда просто встаёт колом: ввод не работает, прокрутка не работает, меню не открываются. Не тормозит, а просто перестаёт отвечать какое-то время.
            Проект использует cmake, оперативной памяти хватает, процессор естественно загружен, но другие приложения в этот момент отзывчивости не теряют вообще.


            С чем, на ваш взгляд, такое поведение может быть связано и как можно исправить? Вещь исключительно специфичная для CLion, как я уже сказал — на другие приложения не распространяется и если, например, использую vscode с настроенным cmake tools, то тоже фризов нет вообще.

              0

              Аналогичная проблема. Заметил, что если запускать другие сборки с nice типа 10 или 19, то ничего колом не встаёт.

                0
                Если это именно фриз IDE, то в директории с логами должен быть thread dump автоматический. Посмотреть бы на него. Была когда-то похожая жалоба, но без каких-то дампов/логов мы разобраться не смогли. Если сможете дампы найти, приложите к запросу этому, пожалуйста, мы обязательно посмотрим, в чем там дело.
                  0
                  С чем, на ваш взгляд, такое поведение может быть связано и как можно исправить?

                  У меня была похожая ситуация. Оказалось дело в GC, Java GC если точнее.
                  После серии мега фризов сама IDE предложила увеличить макс. размер
                  используемой памяти для jvm и все не то чтобы залетало, но подвисание UI исчезло.

                    0

                    У меня под clangd выделено 8Гб + MaxHeap для Java тоже 8Гб установлен. Не сказал бы что что-то изменилось когда в своё время поднял показатели, да и два инстанса CLion занимают до 10Гб в сумме.

                  +1
                  Отлично, спасибо за шикарные новости (особенно про отладчик msvc)!

                  Пара небольших идей:
                  1) Могли бы вы, пожалуйста, запилить показ значений переменных из cmake, например, при наведении курсора на ней? Было бы очень удобно, и сделать вроде бы несложно, т.к. они лежат в cmake кэше.
                  2) Когда на windows я делаю Install проекта, то всегда сталкиваюсь с досадой от того, что требуются права админа на запись в program files, приходится перезапускать clion. Было бы здорово автоматически запрашивать их повышение.
                  3) Swap двух строк через ctrl+shift+up/down очень часто выдаёт совершенно неожиданный результат. Я хочу просто поменять две строки местами, но, как правило, у автоформаттера на это свои планы. В результате я своппером не могу пользоваться.

                  Спасибо!
                    0
                    Спасибо!

                    1) Могли бы вы, пожалуйста, запилить показ значений переменных из cmake, например, при наведении курсора на ней? Было бы очень удобно, и сделать вроде бы несложно, т.к. они лежат в cmake кэше.


                    Только CMake Cache или вообще переменных? (в общем случае, попахивает отладчиком, и кстати такие попытки были, есть даже 3rd party плагин для старых версий CMake). Я вот тут завела реквест, но наверное хорошо бы случаи использования поподробнее там описать.

                    2) Когда на windows я делаю Install проекта, то всегда сталкиваюсь с досадой от того, что требуются права админа на запись в program files, приходится перезапускать clion. Было бы здорово автоматически запрашивать их повышение.


                    Завинула в реквест

                    3) Swap двух строк через ctrl+shift+up/down очень часто выдаёт совершенно неожиданный результат. Я хочу просто поменять две строки местами, но, как правило, у автоформаттера на это свои планы. В результате я своппером не могу пользоваться.


                    Хорошо бы пример. Можно сразу в трекер.
                    Но в целом, автоформатирование используется во многих действиях в CLion. Следует, наверное, настроить правила форматера так, как вам надо, и тогда проблем не будет.
                      0
                      По поводу install и на лиунксе надо) та же проблема, приходится перезапускать.
                        0
                        Отпишитесь в тикете. Наверное, если делать, то не важно где.
                      0
                      3) Swap двух строк через ctrl+shift+up/down очень часто выдаёт совершенно неожиданный результат. Я хочу просто поменять две строки местами, но, как правило, у автоформаттера на это свои планы. В результате я своппером не могу пользоваться.

                      Я в таких случайх использую Alt+Shift+Up/Down, это простое перемещение строк без учета семантики конструкций и без вызова форматтера. Попробуйте, может, найдёте использование этих экшнов для себя более удобным, например, в сочетании с Expand/Shrink Selection перед перемещением строк.

                      0
                      Вопросище. Почему так сложно и непонятна и не интуитивно настраивается удаленная отладка и деплой.
                      Собственно если сравнивать с qt creator.
                      Основная притензия я так и не понял как задеплоить и автоматом запустить под gdbserver'ом приложение.
                      Есть arm с linux, приложение собирается, задеплоить тоже вродее более менее понятно, но вот чтобы запустить отладку предлагается запускать вручную gdbserver на этом арме. Хотя уже есть настроеный ssh и ide моглабы сама это сделать.
                      Почему нельзя как в qt creator нажать кнопку run debug и ide сама убъет если запущенно приложение + возможность добавить кстомные скрипты(например перемонтировать файловую систему или еще что). Задеплоит новую верси. Сама стартанет gdbserver и подключится к нему.
                        0
                        Так можно же! Для этого и сделана новая Embedded GDB Server конфигурация. Почитайте в посте.
                          0
                          Нет, это не то. Это когда совсем малый арм и мы по openoncd подключаемся.
                          Я говорю когда удаленная отладка на большом арм с линуксом.
                          Тоесть на другом конце у нас полноценный линукс с ssh и вот хочется чтобы ide залезала туда по ssh убивала инстансы деплоила приложение и запускала там gdbserver(обычнй) и подключалась к ниму.
                            +1
                            А, я поняла, в чем разница.

                            Смотрите, какие есть сейчас варианты:
                            1. Локальная embedded отдалдка через gdbserver, который CLion запустит сам, через новые конфигурации
                            2. Remote GDB режим, но gdbserver надо запускать вручную (но мы планируем научить CLion его запускать самостоятельно — задача сейчас в разработке)
                            3. Полноценный remote режим, но это не то, что вам сейчас нужно совсем


                            В принципе, в этой embedded GDB server конфигурации можно немного подкрутить, чтобы работать с ней через удаленное соединение. Просто вместо локального gdbserver-а надо указать скрипт, который пойдет по ssh и запустит gdbserver на другой стороне. Elmot может помочь с деталями. Высока вероятность, что оно заработает.

                            Ну и надеюсь, что в 2019.3 мы таки закончим с CPP-7050, которую я упоминала раньше.
                              0
                              Да вот видиммо мне именно 7050 нужно. Буду с нетерпением ждать.
                                0
                                Пока оно не сделано, можно попробовать со скриптом workaround.
                        0
                        Кстати, CLion стал как будто бы шустрее работать, иногда кажется, что даже быстрее MSVS(вынужден использовать на работе).
                        К сожалению, экспериментальный отладчик у меня не взлетел: то ли он падает вместе с отлаживаемым процессом на дефолтном «hello world», то ли просто отладка отваливается (срабатывает бряк, начинаю изучать стек, через секунду в статус-баре вижу process finished и отладка заканчивается), ну да ничего, на то он и экспериментальный.
                          0
                          Не, ну он не настолько экпериментальный) Все же у нас он много, где работает, и довольно стабильно. А можно попросить вас создать запрос в трекере и приложить туда логи IDE с доп. информацией из отладчика. Как ее собрать, описано тут.
                          0
                          Скажите, я понимаю что было в планах в начале добавить Makefile и уже потом остальные. Но вопрос конкретно более лучшей работы с Qt, то есть даже сам а работа с qmake не важна как работа с макросами, сигналами, слотами, дефайнами, дебагинг(на данный момент нельзя увидеть Qt обьекты, пример QString), то есть те вещи которые касаются именно Qt но как я понимаю отношения к API Project model не имеют. Сейчас у нас несколько программистов, пишим все в CLion а дебажить приходится Qt Creator открывать, или если надо из того же Q_PROPERTY сгенерировать методы(слоты и сигналы). Этот вопрос очень сильно волнует.
                            0
                            У Qt есть pretty printers, которые можно просто взять и заиспользовать в CLion. Передайте их через .gdbinit, который в home директории, и все будет работать.
                              0

                              А поддержка .gdbinit в директории проекта есть?
                              Пихать проектозависимые пути/параметры в корневой конфиг — это ну такое себе.


                              В связанном с этим случае сегодня заметил, что запуская GDB через "Attach to process" он своей рабочей директорией считает не корень проекта, а $HOME и поменять это никак нельзя из настроек. Запуск в домашней директории и локальный .gdbinit решили бы некоторое количество проблем и устранили дикий костыль в виде использования глобального конфига.

                                0
                                Пока нет( Но был план это поддержать в ближайшее время.
                            0
                            А умеет ли CLion из коробки работать со всякими андроид студиями и т.п.? Как Qt?
                              0
                              Что значит работать с Android Studio? Это же отдельная IDE, на базе IntelliJ-платформы, мало того с C++ поддержкой из CLion)
                              0
                              CLion — один из немногих продуктов, которые мне приятно использовать. Но некоторые вещи просто бесят! Исправьте баг youtrack.jetbrains.com/issue/CPP-15774!!!
                                0
                                Я так понимаю, что не работает в случае дефолтового значения для cmake.parallel.generation опции. Так?
                                Боюсь, что без примера для воспроизведения будет очень сложно поправить. Мы сами такое не наблюдаем, а в логах ничего подозрительного нет. Но мы попробуем еще раз глянуть.
                                  –3
                                  Я так понимаю, что не работает в случае дефолтового значения для cmake.parallel.generation опции. Так?

                                  Так.
                                  Но я ж не могу отправить вам мой проект для тестирования!
                                  А делать некую симуляцию я тоже не могу (не хочу), мне за это не заплатят, а я вам плачу, между прочим :)
                                    0
                                    Крайне интересно, этот «минусатор» сколько создал баг-репортов, сколько времени потратил на бесплатное тестирование коммерческих приложений, сколько накоммител в open-source проекты?
                                      +1
                                      С одной стороны, вы правы. А с другой, если мы совсем никак не можем проблему воспроизвести, то поправить ее тоже очень тяжело. Особенно, если в логах ничего подозрительного и необычного нет вообще. Вот такая печальная история.
                                        0
                                        Так это вы были? Удивляюсь, ну да ладно. Я писал, как можно воспроизвести этот баг. Напишу еще раз — создайте CMake проект с использованием OpenMP и protobuf, например.
                                          0
                                          Минусовала не я, если что)
                                            0
                                            Обычно, все это не так просто. Ну то есть, мы наверное попробуем еще раз, конечно, но по опыту такие вещи так легко не удается воспроизвести.
                                    0
                                    Обновился.
                                    Реализовали подсказки для аргументов вызова функций

                                    Подсказки появляются не для всего. Сходу напоролся на два кейса на картинках.

                                      0
                                      Они действительно показываются не для всего, by design. А только там, где это реально необходимо / непонятно.
                                      Подсказки показываются в тех случаях, когда действительно сложно понять, какие значения каким параметрам передаются, а именно, в случае использования в качестве аргументов вызова литералов или выражений более чем с одним операндом.
                                        0
                                        Хорошо, имитируем ситуацию: человек перепутал аргументы.

                                        Имхо необходимость есть.
                                          0
                                          Если человек переаутывает аргументы одного типа, есть отличный чек в анализаторе в CLion, который такое ловит: argument selection defect

                                          Я при этом соглашусь, что странно показывать хинт перед nullptr и не показывать его перед NULL. Видимо такое откинулось по эвристикам. Завела тикет на это. Поправим.

                                          Просто в целом, если расставить parameter hints везде, будет очень много шума. Но общая рекомендация — если вам кажется, что еще где-то они могут быть полезны, то создайте запрос в трекере с описанием примерам.
                                        0

                                        NULL — это вполне себе литерал, к примеру.

                                          0
                                          да-да, я ответила выше. В кратце, завела багу) Перед nullptr он покажется при этом.
                                      0
                                      Конечно, нас часто спрашивают про улучшения производительности. Я повторюсь, для нас это наиболее приоритетная задача, но точечных изменений получается сделать не много, а глобальные требуют времени больше, чем 1-2 релизных цикла.

                                      Неужели задача отказаться от написания проекта на Java и перейти на C/C++ настолько не решаемая? В конце концов, можно даже использовать Qt. А так это будет бесконечный танец вокруг того, что изначально не рассчитывалось на производительность.
                                        +1
                                        Вы правда думаете, что дело только в том, что платформа именно на Java?)

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

                                        Во-вторых, дело ведь не в том, что она на Java. Дело в том, что ее архитектура не была изначальна расчитана на C++, где на каждый чих нужно код именно резолвить, а не просто парсить. Ну потому что даже чтобы покрасить правильно плюсовый код надо понять перед вами тип или не тип, то есть резолв сделать контекстный. Так что Java как таковая тут не при чем.

                                        Теперь из хорошего:
                                        — пока что кажется, что проблемы, которые есть решаемые на текущей платформе, просто требуют времени (гораздо меньшего, чем написать все с нуля)
                                        — второй парсер у нас кстати на C++ (на кланге), но на нем пока глобальные действия нельзя делать (просто еще в мире никто толком не научился, все экперименты пока гораздо медленнее, чем даже наш «тормозной» Java-парсер ;) )
                                        — проблемы, на самом деле, не только в C++, в некоторых других языках тоже встречаются, так что проблемы эти решает не только CLion, а вся команда платформы
                                          –2
                                          Вы правда думаете, что дело только в том, что платформа именно на Java?)
                                          Где я такое написал? О_О

                                          платформе 19 лет уже и она вылизана довольно хорошо
                                          Это — заблуждение номер раз. Вылизанных платформ нет. Есть первоначальные задачи, которые ставились перед архитекторами платформы. В число этих задач не входило написание GUI-приложений от слова «совсем».

                                          Дело в том, что ее архитектура не была изначальна расчитана на C++, где на каждый чих нужно код именно резолвить, а не просто парсить.
                                          А это-то тут при чём? О_О
                                          IDE — суть автоматизированные текстовые редакторы, кто бы какие ярлыки на них ни вешал. Для редактируемого текста не имеет значения, на каком языке они написаны. Это имеет значение лишь для разработчика и платформы, под которую пишется само ПО. Не умножайте сущности!

                                          Ну потому что даже чтобы покрасить правильно плюсовый код надо понять перед вами тип или не тип, то есть резолв сделать контекстный
                                          А для работы с программным кодом на других языках как будто не требуется статического анализатора?

                                          Так что Java как таковая тут не при чем.
                                          Согласен, язык программирования ни при чём. А при чём виртуальная машина, предназначенная исполнять байт-код — результат компиляции этого самого языка, и её архитектура, которая аукается даже после Jit-компиляции.

                                          проблемы, которые есть решаемые на текущей платформе
                                          Безусловно они есть и решаемы в рамках текущей платформы, но они не столь фундаментальны, как вопрос использования этой «платформы». Программной, прошу заметить, платформы, не аппаратной. Java создавалась для решения совершенно иных задач. Это — инструмент для разработки backend-ПО в среде WEB. Но его ошибочно использовали для разработки мобильного ПО, а дальше и на desktop переползло… Всему причина — цена отладки ПО, за которую бизнес бездумно, без каких-либо тормозов вцепился, как в «ману небесную». Теперь сам же пожинает плоды этого решения. Конечно же производители «железа» дружно промолчали — им это выгодно. Вот интересное решение для обособленных задач под названием Java превратилось в проблему.

                                          гораздо меньшего, чем написать все с нуля
                                          Согласен, решение, лежащее в основе проекта, влечёт впоследствии к зависимости от него. Подобное утверждение корректно по отношению к любому языку программирования. Но, ведь, проблема-то не в языке. Даже в C++ есть ряд провалов по производительности относительно языка C, а у последнего — относительно Assembler-а.

                                          второй парсер у нас кстати на C++ (на кланге)
                                          Может стоило приложиться тогда к доработке его фукционала под свои требования? Open Source же, ё-моё!

                                          проблемы эти решает не только CLion, а вся команда платформы
                                          Чтобы ПО на Java было столь же производительным, под него нужно менять архитектуру процессоров.
                                            0
                                            Я не буду вмешиваться в дебаты про Java, это кажется не очень продуктивно. Отвечу вот про какие моменты:

                                            IDE — суть автоматизированные текстовые редакторы, кто бы какие ярлыки на них ни вешал. Для редактируемого текста не имеет значения, на каком языке они написаны.


                                            Я не про то, на каком, а про то, для какого. Есть разница — писать IDE для Java или для C++.

                                            А для работы с программным кодом на других языках как будто не требуется статического анализатора?


                                            Издалека начну. Любая IDE — это баланс между «умностью» (подсветка, форматирование, автодополнение, анализаторы, рефакторинги, и так далее) и «производительностью». В некоторых языках — этот баланс поддерживать очень легко. Пока мы создавали архитектуру платфорфмы многие годы, мы не имели планов делать IDE для C++. А потом она появилась. И выяснилось, что там, где для Java/Python/Ruby действие ничего не стоит, в C++ оно тянет за собой зачастую огромный резолв кода.

                                            Кстати поэтому по началу даже многие фризы было поправить просто — нашел такое место, быстро извел резолв, бинго! Правда, простые места быстро закончились.

                                            И да, можно написать подсветку кода для таких простых языков на лексере, а в C++ нельзя. Потому что есть вот такие примеры. И пробелы даже правильно в C++ не расставить без резолва, я на эту тему на C++Now в докладе с аудиторией в отличную игру играла. Там вообще в целом весь доклад именно про то, почему с C++ история оказалась в разы интереснее и сложнее. Похожие проблемы я знаю еще в Scala, например.

                                            Так что гораздо больше, чем производительность самого языка, на котором написана IDE, важнее, для какого языка она написана.

                                            Ну и про:

                                            Может стоило приложиться тогда к доработке его фукционала под свои требования? Open Source же, ё-моё!


                                            Звучит и правда заманчиво. Мы ж не зря решили в это влезть. Но вот прямо сейчас у нас, например, есть вера, но не уверенность, что оно вообще взлетит. Для действий на всем проекте (типа рефакторингов, find usages, и пр) надо в кланг напихать все те 100500 оптимизаций, отложенных резолвов и пр., которые уже заимплементированы в нашем изначальном Java-парсере. Они самому клангу нафиг не упали (это по сути же компилятор, ему такие оптимизации не нужны). Да и успех этого мероприятия пока под вопросом, хотя мы и экспериментируем. Переводим на кланг все неглобальные действия и пробуем обучить его делать глобальные действия.

                                            Кстати, интересный факт, вот модули появились почти в языке. Они заставят всех производителей IDE фактически компилятор C++ к себе в парсер запихать. Но верите или нет, наш оптимизиронный «медленный» Java-парсер, показывает производительность по индексации лучше, чем просто взять и клангом все это добро обрабатывать так, как это кланг как компилятор делает.
                                              0
                                              Я не буду вмешиваться в дебаты про Java, это кажется не очень продуктивно
                                              Ну, если делать выжимку по теме, то звучит она так: IDE для C++, ИМХО, лучше писать на языках, компилируемых в набор инструкций процессора. Ибо подсветка — ещё цветочки, а запуск программы в debug-режиме — вот это уже нагрузка серьёзная.

                                              Кстати, уже который раз ищу, но не нахожу подобного проекта: Неужели никто не задумывался о реализации JRE из OpenJDK в виде модуля ядра?

                                              И да, можно написать подсветку кода для таких простых языков на лексере, а в C++ нельзя. Потому что есть вот такие примеры.
                                              Ну, define подсвечивать, по моему скромному мнению, просто незачем. Впрочем, здорово, если такая функция имеется, но сам он — своего рода «костыль», без которого под час просто никуда.

                                              надо в кланг напихать все те 100500 оптимизаций, отложенных резолвов и пр., которые уже заимплементированы в нашем изначальном Java-парсере
                                              Тогда проще создать свой анализатор, чтобы органично согласовать с логикой IDE.

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

                                              Но верите или нет, наш оптимизиронный «медленный» Java-парсер, показывает производительность по индексации лучше, чем просто взять и клангом все это добро обрабатывать так, как это кланг как компилятор делает.
                                              Охотно верю. Сам его прикручивал в проект: тяжёлая штука. Но он не единственный противоречивый пример.

                                              В одном проекте, написанном на C++/Qt, ядро парсера данных было лишено вкраплений Qt, а во многих местах даже на «голом СИ». Причина — жёсткие требования к производительности. Стояла задача выводить в генерируемом графическом контексте надписи с различной обработкой в качестве, не уступающем самой ОС.

                                              Применили FreeType, т.к. он показал хорошую производительность. Однако, эта библиотека не могла определить габариты глифа символа без его полного рендеринга. Представляете, чего стоила задача предварительно оценить габариты надписи? Пришлось кэшировать эти самые габариты посимвольно коллекциями в памяти для ускорения. Нет, внутри библиотеки нашли внутренние методы оценки, но применять не стали, чтобы не включать библиотеку в проект. Тем более, что под Windows используется WinAPI. А влить в багтреккер так же не могли из-за глухой закрытости проекта.

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

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