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

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

image


Коротко об основных улучшениях для тех, кто не хочет много читать:

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

    • Улучшения в таких подсистемах парсера, как list initialization и name lookup
    • Поддержка расширений специфичных для компилятора Microsoft Visual C++
    • Поддержка макроса __COUNTER__
    • И не только!
  • Новые инструменты и фреймворки

    • Valgrind Memcheck
    • Boost.Test
    • CMake 3.9, GDB 8.0, LLDB 5.0
  • Существенные переработки и расширение возможностей в настройке компилятора, окружения, CMake, отладчика, и пр.
  • Возможность запуска почти произвольной функции main, иконки для запуска функций main и тестов
  • Возможность разрабатывать на Kotlin/Native в CLion

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

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


Глобальные улучшения


Практически все, наверное, знают, что мы пишем свой парсер для C++. Это вызывает разнообразные дискуссии, как среди наших пользователей (такие дискуссии зарождаются под любым нашим постом здесь на Хабре, reddit и пр.), так и внутри команды. Тем интереснее нам одновременно и улучшать текущее решение, и думать о возможных альтернативных вариантах (мы, кстати, ни один полностью не исключаем!). А в последнее время мы задумали глобально переработать наше решение, начав с подсистем, которые лежат в самом низу, и постепенно поднимаясь наверх. Версия CLion 2017.3 затронула list initialization и name lookup.

В случае list initialization, исправления, в основном, привели к тому, что CLion больше не показывает некорректные предупреждения вроде “too many arguments”, “too few arguments”, “no matching constructor”. И, напротив, показывает их теперь там, где это нужно:
image

К тому же, CLion теперь умеет корректно понимать переменные в случае uniform initialization:
image

Другая область исправлений в этом релизе – name lookup. Правильное ассоциирование имени переменной с ее декларацией – одна из базовых задач языковой поддержки. Проблемы на этом этапе приводят к неправильным сообщениям анализатора кода, некорректной кодогенерации и т. д. Основные исправления были связаны с правильным порядком резолва и с резолвом переменных, которые передаются в область видимости через конструкцию using или с помощью наследования типов:
image

Поддержка расширений MSVC


Если у вас на машине установлен Microsoft Visual C++ компилятор, то вы можете включить экспериментальную поддержку MSVC в CLion и использовать этот компилятор вместо GCC и Clang. Экспериментальной поддержка была названа по нескольким причинам:

  1. Изначально CLion не поддерживал никакие специальные расширения MSVC языка C++
  2. В случае MSVC в CLion не доступен отладчик

CLion 2017.3 включает исправления для первого пункта. Поддержаны такие расширения, как __uuidof, __unaligned/__alignof, __ptr32/64 и другие. Полный список доступен в нашем блоге.

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

Другие полезные улучшения в поддержке C++


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

  • Поддержку макроса __COUNTER__. Его значение теперь честно вычисляется, а значит, CLion больше не покажет, например, некорректное предупреждение про “duplicate declaration”. А в Quick Documentation окне (Ctrl+Q на Linux/Windows, F1 на macOS) можно увидеть результат макро-подстановки:
    image
  • Генерация определений (Shift+Ctrl+D на Linux/Windows, ??D на macOS) для функций теперь корректно работает в случае шаблонов функций.
  • Добавлена поддержка популярного шаблона рефакторинга – инвертирования if-else блоков. Данный шаблон часто используется для упрощения кода, который использует множество вложенных if блоков.

Для разработчиков аудио приложений


Отдельно хочется рассказать про улучшения для тех, кто разрабатывает мультиплатформенные аудиоприложения. Для такой разработки существует очень известная библиотека на C++ – JUCE. В CLion 2017.3 мы исправили несколько проблем в языковой поддержке, которые возникали в случае использования JUCE.

Но главной новостью для пользователей JUCE стал выход JUCE 5.2, где в новой версии Projucer добавлена возможность экспортировать проект в CMake. А значит и открывать его для дальнейшей разработки в CLion! Мы даже записали короткое демо, в котором создаем демо аудиоплагина, экспортируем его в CMake, открываем в CLion, запускаем плагин в Ableton Live и отлаживаем его через CLion!

Интеграция с Valgrind Memcheck


Одним из самых востребованных запросов у нас в трекере является интеграция с инструментами профилирования, в частности с Valgrind. В этом релизе мы начали с самого ключевого – добавили возможность профилирования памяти с помощью Valgrind Memcheck.

В отличие от Google Sanitizers, которые тоже часто используются для этой задачи, Valgrind Memcheck поддерживает множество платформ (но, к сожалению, как и Sanitizers, не доступен на Windows). Он не требует перекомпилирования программы и работает с исполняемым файлом, собранным с помощью как Clang, так и GCC. При этом инструмент позволяет идентифицировать целый спектр проблем в работе с памятью:

  • Утечки памяти
  • Некорректный доступ в память, например, после вызова free
  • Несоответствие операций выделения и освобождения памяти (malloc/free, new/delete)
  • Использование неинициализированных переменных
  • Передача в качестве параметров в функции типа memcpy пересекающихся областей памяти
  • Передача в функции выделения памяти некорректного размера, например отрицательного

Теперь в CLion можно запустить конфигурацию с Valgrind Memcheck и в окне результатов запуска получить информацию о потенциальных проблемах, включая кусок стека, соответствующий проблеме, и предпросмотр места в коде, где случилась проблема. Настройки позволяют задать так называемые suppression файлы (для отключения анализа в библиотеках, например) и опции для запуска Valgrind Memcheck.
image

Улучшения в сфере модульного тестирования


Интеграция с фреймворками для модульного тестирования в CLion подразумевает запуск тестов во встроенном окне с выводом результатов (test runner). Если раньше поддерживались Google Test и Catch, то теперь еще добавили Boost.Test:
image

Кстати, в левой боковой колонке (“гаттере”) можно заметить новые значки. Они работают для всех трех поддерживаемых фреймворков и служат для запуска тестов – нажав на них, можно выбрать запуск, отладку или запуск с Valgrind Memcheck. А после первого запуска тестов значок меняет вид и начинает отображать статус теста – пройден или упал. Довольно удобно, если хочется открыть файл с недавно запущенными тестами и быстро понять, что и как.

Аналогично, с помощью значка в левом гаттере можно запускать любую функцию main, для которой найдется CMake таргет (без таргета довольно тяжело понять, что именно и как запускать). А вот Run конфигурацию создавать не обязательно – CLion создает ее автоматически при нажатии на иконку.

Настройки тулчейнов, компилятора, CMake


Уже почти традиционные осенние изменения в области CMake и настройки тулчейнов и конфигураций не обошли стороной и этот релиз. Главное:

  1. Появилась возможность сконфигурировать в IDE несколько тулчейнов и выбирать нужный для каждого проекта, или даже использовать несколько разных для разных таргетов на одном проекте. Особенно это актуально будет пользователям на Windows, которые хотят легко и быстро переключаться между окружениями Cygwin/MinGW/MSVC:
    image
  2. Появилась возможность легко переключать компилятор C и C++, а также Make. Теперь это можно сделать в настройках тулчейна, упомянутых выше.
  3. Появилась возможность создать несколько CMake профайлов с одним и тем же типом билда (Debug, Release, etc.), но разными опциями, настройками окружения, используемыми тулчейнами (например, компиляторами) и пр.:
    image
  4. CMake-профайл теперь не связан напрямую с запускаемой run/debug конфигурацией, а выбирается независимо:
    image

Новые версии отладчиков и CMake


В CLion 2017.3 мы включили в поставку обновленные версии следующих инструментов:

  • CMake обновили до 3.9
  • GDB обновили до 8.0
  • LLDB обновили до 5.0

Стоит отметить, что GDB 8.0, который поставляется вместе с CLion, собран с поддержкой нескольких архитектур. А это означает, что при удаленной отладке между разными платформами (например, с Windows на Linux) не потребуется больше пересобирать GDB, а можно будет воспользоваться встроенным.

Kotlin/Native


Наверняка многие из вас знают, что компания JetBrains создала и активно разрабатывает новый язык программирования Kotlin, который в этом году на Google I/O был официально признан языком для разработки Android-приложений. А еще у нас есть проект Kotlin/Native, который позволяет компилировать Kotlin напрямую в машинный код таких платформ как iOS, Linux, Windows, macOS и WebAssembly.

Вы спросите, причем тут CLion, IDE для кросс-платформенной разработки на C и С++? Дело в том, что Kotlin/Native интегрируется с такими технологиями из мира нативной разработки, как Clang и LLDB. А CLion, в свою очередь, рассматривается нами как IDE для нативной разработки, в которой уже есть поддержка C и С++ как основных языков, а также Python, Swift и Rust как дополнительных (все в рамках CMake пока что). Поэтому вполне естественно было выпустить плагин для разработки на Kotlin/Native именно для CLion. Больше подробностей можно найти в блоге Kotlin. А в будущем можно ожидать появления Kotlin/Native и в других наших инструментах.

На этом я закончу обзор новых возможностей CLion 2017.3. Есть, конечно, еще и обновления в поддержке систем контроля версий и другие возможности, пришедшие из платформы IntelliJ. Но я не буду повторяться и просто сошлюсь на блог пост про IntelliJ IDEA 2017.3 здесь на Хабре.

Демонстрация новых возможностей CLion 2017.3 на английском языке от нашего девелопер-адвоката:



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

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

Ваша команда JetBrains CLion
The Drive to Develop

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


  1. BiTHacK
    06.12.2017 19:57

    Оценок сроков реализации поддержки Qt+qmake не появилось?


    1. anastasiak2512 Автор
      07.12.2017 00:48

      Ответ ниже в комментариях (с телефона промахнулась мимо треда)


  1. anastasiak2512 Автор
    06.12.2017 20:39

    Сейчас начнём потихоньку отвязывать CLion от CMake, а там можно будет делать другие билд-системы. Но кажется, что первой будут Makefiles


    1. VioletGiraffe
      06.12.2017 20:55
      +1

      Тоже зашёл в комментарии спросить о qmake.
      Makefiles, как правило, тривиально получаются вызовом qmake -r в корневой папке, только нужно найти нужный бинарник qmake (от целевой версии Qt).


      1. anastasiak2512 Автор
        06.12.2017 21:41

        Там самая большая проблема, что нам надо из билд системы получить кучу информации о проекте. А сейчас CLion такую информацию только из CMake умеет получать. Это информация нужна для корректного парсинга/резолва кода.


        1. melon
          07.12.2017 00:03

          ещё было бы неплохо Ninja добавить. Говорят, она в некоторых случаях сильно ускоряет компиляцию больших проектов.


          1. anastasiak2512 Автор
            07.12.2017 00:49

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


      1. Bragaman
        06.12.2017 22:19

        Немного опередили, жду поддержку Qt и qmake последний год


    1. crea7or
      07.12.2017 02:26

      нинзю/gn давайте чтобы с хромом работать.


      1. anastasiak2512 Автор
        07.12.2017 09:32

        Хромиум? С ним, боюсь, не только в ninja проблемы.


        1. crea7or
          07.12.2017 10:56

          ну clion падает на импорте и зависает — это да. Ну вы же должны быть лучше vs, а он почти тянет проект.


          1. anastasiak2512 Автор
            07.12.2017 14:50

            Не, ну если увеличить xmx (память), то мы сможем открыть. Но проект, конечно, очень тяжелый.


            1. crea7or
              07.12.2017 21:03

              Увеличивал и открывал таки, но с таким скрипом работает — при обновлении подвисает намертво. Хромиум не такой большой как кажется, там 2/3 third_party библиотеки, который нужны только по особым случаям.


              1. anastasiak2512 Автор
                08.12.2017 02:23

                Работать как-то с Хромиумом действительно очень тяжко. Для нас это хороший референсный проект. Когда там все будет хорошо, в других местах все будет просто отлично по перфомансу!


            1. Daffodil
              08.12.2017 03:47

              Я увеличил до xmx до 8 GB, работаю с Clang/LLVM. В принципе жить можно. Местами конечно притормаживает. Тот же QtCreator пока быстрее проект открывает, и в целом code completion шустрее работает. Но у них к сожалению очень всё сыро. Даже нормальную поддержку auto до сих пор не сделали.


    1. akamensky
      07.12.2017 07:40

      Makefiles! Makefiles! Скорее бы уже. Я каждый день использую либо Go[g]Land, либо PyCharm, либо NetBeans, ибо CLion все-еще не поддерживает GNU make, и как-то становится обидно что плачу за весь toolbox, а пользуюсь только на 2/3.

      Хоть какой-нибудь примерный ETA можете подсказать, когда нам уже придет счастье?


      1. anastasiak2512 Автор
        07.12.2017 09:33

        Планируем в 2018 этим заняться.


    1. alexey-m-ukolov
      07.12.2017 08:50

      1. anastasiak2512 Автор
        07.12.2017 09:35

        Вы про UI для pretty printers? Не добрались пока. Но вот ошибку, которая там обсуждалась, мы поправили.


    1. DarkEld3r
      07.12.2017 13:36
      +1

      Сейчас начнём потихоньку отвязывать CLion от CMake

      Ура. Для С++ меня CMake вполне устраивает, но отвязка от него крайне полезна для других языковых плагинов (в первую очередь, заинтересован в этом).


      1. anastasiak2512 Автор
        07.12.2017 15:12

        Да, Rust-плагин как раз один из основных драйверов такой деятельности сейчас.


        1. DarkEld3r
          07.12.2017 16:20

          Приятно слышать. Надеюсь, что растовый плагин когда-нибудь дорастёт и до полноценной отдельной IDE.


        1. 0xd34df00d
          07.12.2017 20:26

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


          1. anastasiak2512 Автор
            08.12.2017 02:25

            Не думали. Но есть плагин, правда в довольно заброшенном состоянии и не знаю, насколько он хорошо в CLion работает.


            1. 0xd34df00d
              08.12.2017 02:40

              Да, я его пробовал несколько месяцев назад. В CLion он не работает вообще, в специально скачанной под это дело Idea он как-то делает вид, что работает (менюшки всякие добавляет, настройки и типы проектов), но толку от него мало.

              В принципе, язык-то в смысле синтаксиса дубовый, а система типов всё довольно сильно упрощает. От IDE-то в этом случае нужно только понимание проектных файлов (а они простые), умение переходить к определениям функций (что, в принципе, понятно как делать) и статический анализ (можно дёргать уже существующий сервер hdevtools, который прямо для этого создан, и hlint, например). Всякие рефакторинги — это уже дело десятое.


              1. anastasiak2512 Автор
                09.12.2017 03:50

                У нас пока столько задач, что не до Хаскеля. Так что если только кто-то плагин сделает


    1. Falstaff
      07.12.2017 13:43

      А поддержка CMake сохранится на прежнем уровне? Уж очень сейчас удобно, что проект CMake — одновременно и проект CLion, и не требуется никаких промежуточных телодвижений (вроде того что в Eclipse, когда приходится из CMake генерировать нативный проект Eclipse и уже с ним работать).


      1. anastasiak2512 Автор
        07.12.2017 15:12

        Да, вводить какую-то свою проектную модель не планируется. Хочется именно, добавлять новое.


  1. Tantrido
    06.12.2017 21:05

    Новые инструменты и фреймворки — Valgrind Memcheck
    Т.е. в Windows это не работает?


    1. anastasiak2512 Автор
      06.12.2017 21:43

      К сожалению, нет. И даже запланированные на 2018.x Google Sanitizers делу не помогут — они тоже не работают на Windows.


      1. slonopotamus
        06.12.2017 23:00

        Почему к сожалению?


        1. anastasiak2512 Автор
          06.12.2017 23:20

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


  1. m1n7
    06.12.2017 23:38

    По-прежнему нет полноценного нечеткого поиска:(


    1. anastasiak2512 Автор
      07.12.2017 00:50

      А что Вы имеете в виду под «нечетким поиском»?


      1. m1n7
        07.12.2017 10:17

        image


        Атом и саблайм так умеют, а клион — нет. Очень не хватает.


        1. anastasiak2512 Автор
          07.12.2017 16:27

          Вот тут есть реквест, но пока, как я знаю, никаких планов на этот счет нет.


  1. apro
    07.12.2017 00:02

    Практически все, наверное, знают, что мы пишем свой парсер для C++

    Насколько я слышал вы пишете не просто свой парсер, а два своих C++ парсера?
    Один в CLion другой в resharper. Или вы все-таки решили один делать?


    1. anastasiak2512 Автор
      07.12.2017 00:52
      +1

      Два, потому что архитектура IntelliJ-платформы и ReSharper-а разные. Они даже на разных языках написаны (Java & Kotlin и C# & C++) (по секрету, мы их уже больше двух написали, пока экспериментируем с разными решениями =) ).


      1. apro
        07.12.2017 02:40

        по секрету, мы их уже больше двух написали

        Жаль, что при таком подходе чуда все-таки не произошло.
        Как было много подкрашено красным в полностью валидном проекте (CI его собирает на нескольких платформах несколькими разными компиляторами)
        в самой первой доступной версии clion (2-3 года назад?), так и сейчас не понимает очевидные вещи типа:


        std::pair<std::string, size_t> f() { return std::make_pair(std::string("a"), size_t(1)); }
        std::pair<std::string, size_t> val;
         val = f();

        говорит что pair::operator= deleted, хотя очевидно что это не так.


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


        1. anastasiak2512 Автор
          07.12.2017 09:37

          На самом деле, польза от этого есть. Много улучшений именно из этого опыта взялось. Где-то пока ещё есть серьезные проблемы, но их существенно меньше, чем, скажем, 2 года назад. Попрошу ребят посмотреть на конкретный пример. Спасибо.


        1. anastasiak2512 Автор
          07.12.2017 14:48

          Пример, похоже, вот про это.


        1. khim
          07.12.2017 16:26

          Но Москва не сразу строилась, может быть через лет 5 уже вашу IDE будут
          использовать для проверки правильности работы компилятора.
          А разве JetBrains собираются писать компилятор? Как уже обсуждалось без приличного фронтенда («умеющего», в частности, вычислять значения constexpr-переменных — а это уже приличный такой шмат «полного» C++) вы даже AST не построите!


  1. valexey
    07.12.2017 03:12

    А это нормально, что у меня после обновления в проекте теперь иногда исполняемый файл не соответствует текущему подпроекту?

    То есть если я хочу запустить или отладить подпроект A, то у меня запускается исполняемый файл подпроекта B. Приходится тыкать в Edit Configuration… и править там руками.

    В 2017.2 такой проблемы не было.


    1. anastasiak2512 Автор
      07.12.2017 09:42

      Наверное, лучше в трекер с примером и деталями прийти. Исполняемый файл в run/debug конфигурации берётся из соответствующего таргета CMake. Каких-то проблем с этим нам не известно. Так что давайте на конкретных деталях разбираться.


  1. Slader
    07.12.2017 10:19

    А как на счёт поддержки clang-format? Хотя бы на уровне qtcreator — при сохранении запускается clang-format для файла/файлов.
    Ну и конечно, поддержка if (auto it = map.find(); it != map.end()) из C++17.
    Вот отсутствие этих двух вещей очень мешает перейти наконец на CLion с qtcreator


    1. anastasiak2512 Автор
      07.12.2017 15:14

      clang-format в самые ближайшие планы пока не попадает, но вообще поддержать его хотим. Хотя бы конвертацию его опций в опции CLion и наоборот.

      C++17 будем делать, начиная с 2018.1.


    1. yeswolf
      08.12.2017 20:39

      Скачайте File Watchers плагин, настройте там clang-format и будет он срабатывать на сохранение.


  1. Arqwer
    07.12.2017 12:28
    +1

    А можете пожалуйста сделать чтобы при автодополнении учитывалась частота использования выражения мной? Сейчас, например я пишу
    bool is_good = f…
    и на первом месте в подсказке отображается какая-то функция на букву f, которую я ни разу не использовал, а false где-то на десятом месте. Хотелось бы наоборот.


    1. anastasiak2512 Автор
      07.12.2017 15:34

      Ну, вообще если часто в комплишене исользуется какая-то функция, она автоматически поднимается в топ в списке. Если же просто usages использовать, это, наверное, слишком сложная метрика… А smart completion не помогает (он фильтрует по типу, когда может)?


  1. KonstantinSpb
    07.12.2017 15:06

    Планируется ли добавление удаленной отладки через SSH на машинах с другой архитектурой процессора, другим toolchain-ом (Raspberry PI и.т.п.)?


    1. anastasiak2512 Автор
      07.12.2017 15:18

      Сейчас есть вариант удаленной отладки через gdbserver, GDB при этом на локальной машине запущен. И скоро начнем работы по поддержке удаленной отладки, когда GDB именно удаленно запускается.


    1. Elmot
      07.12.2017 15:39

      Можно попробовать путем настройки External Tools и Remote GDB. У меня с embedded получилось


  1. canab
    07.12.2017 15:14

    Чего не хватает:

    1. Гибкости настройки Run Configurations
    youtrack.jetbrains.com/issue/CPP-5040

    2. Хоть какой-нибудь ресолвинг символов в макросах
    youtrack.jetbrains.com/issue/CPP-6544


    1. anastasiak2512 Автор
      07.12.2017 15:31

      1. Да, наверное было бы неплохо что-то такое реализовать. Есть еще несколько относительно связанных запросов: CPP-10731, CPP-8848, CPP-7388
      2. Хоть какой-нибудь можно, но хочется чтобы он работал и не втыкал хотя бы в основной массе случаев. Мы пока думаем. Нам про этот запрос часто напоминают.


  1. khrisanfov
    07.12.2017 15:22

    Очень плохо работает функция Evaluate и Watch в отладке, например когда из кастомного списка типа QList вызвать size() в Evaluate выдает ошибку. Это с первых версий не работает. Будет ли исправлено?


    1. anastasiak2512 Автор
      07.12.2017 15:31

      А если подключить pretty printers из Qt через .gdbinit, проблема остается?


  1. Elmot
    07.12.2017 15:34
    +1

    И я, и я хочу попиариться на вас!
    Кому вот CLion для МК?

    plugins.jetbrains.com/plugin/10115-openocd--stm32cubemx-support-for-arm-embedded-development


    1. anastasiak2512 Автор
      07.12.2017 15:36

      Давай второй гостевой блог-пост на эту тему!


      1. Elmot
        07.12.2017 15:55

        Уже написал заголовок.


        И видео.


        1. anastasiak2512 Автор
          07.12.2017 15:59

          Круто! Будем ждать продолжения.


    1. Daffodil
      07.12.2017 21:44

      Вот это очень хорошие новости. Осталось только подтянуть дебаггер до уровня Eclipse.


      1. anastasiak2512 Автор
        08.12.2017 02:26

        А чего именно не хватает в отладчике, подскажете?


        1. Daffodil
          08.12.2017 05:24

          Обычно вендоры электроники сами делают расширения к IDE для отладчика. Чтобы можно было удобно смотреть значения регистров и состояние памяти. Помимо процессорных регистров часто бывают ещё и memory-mapped регистры для периферийных устройств.
          Сейчас вендоры берут Eclipse и сами допиливают его под свои аппаратные платформы. Но я как понимаю Clion не опенсорс, так что в ближайнее время ничего ждать не стоит.


          1. Elmot
            08.12.2017 12:37

            во-первых не такой-то он уж клозед-сорц. там очень много кода от IDEA. Я свой плагин написал без доступа к их закрытым исходникам. anastasiak2512, можно считать это намеком.
            А вообще я собираюсь с духом поддержать в своем плагине SVD файлы, тогда для как минимум для ARM поддержка периферии будет.


        1. Daffodil
          08.12.2017 05:26

          Ну и этот плагин на базе OpenOCD сделан. Но многие аппаратные платформы с OpenOCD не работают. Например у Xilinx и Intel какие-то свои протоколы поверх JTAG накручены.


        1. Elmot
          08.12.2017 12:30

          1. anastasiak2512 Автор
            09.12.2017 03:54

            Первое — прямо сейчас в разработке. Второе — в планах сразу после первого.


            1. Elmot
              09.12.2017 10:40

              Отлично!


        1. Uzix
          09.12.2017 03:53

          Из того, что заметил за несколько минут знакомства: не хватает поддержки cmsis-svd, просмотра содержимого памяти, нормального дизассемблера (сейчас он доступен только если нет исходного кода проекта, насколько я понял).
          В качестве примера хорошего embedded-отладчика можете посмотреть SEGGER Ozone.


          1. anastasiak2512 Автор
            09.12.2017 03:55

            Ок, спасибо. В целом, все разумно, и планируем делать. Просто ресурсы на отладчик у нас пока очень ограничены, а планы то огромные.


          1. Elmot
            09.12.2017 10:41

            А что вы имеете в виду под поддержкой cmsis?


            1. Uzix
              09.12.2017 11:03

              Отображение содержимого регистров memory-mapped периферии. cmsis-svd является общепринятым форматом описания доступных регистров у микроконтроллеров на базе ядра Cortex.


              1. Elmot
                09.12.2017 12:28

                А, я думал что-то еще. Поддержка svd у меня в планах, и что-то мне подсказывает, что я до нее доберусь раньше, чем ребята из jetbrains.


  1. oYASo
    07.12.2017 16:59

    Интеграция с Valgrind Memcheck

    Не прошло и 3.5 лет :)

    Полезных улучшений много, вы молодцы!


    1. anastasiak2512 Автор
      07.12.2017 17:00

      Ну вот наконец ресурсы на это появились. Спасибо)