Оценок сроков реализации поддержки Qt+qmake не появилось?
Ответ ниже в комментариях (с телефона промахнулась мимо треда)
Сейчас начнём потихоньку отвязывать CLion от CMake, а там можно будет делать другие билд-системы. Но кажется, что первой будут Makefiles
Тоже зашёл в комментарии спросить о qmake.
Makefiles, как правило, тривиально получаются вызовом qmake -r в корневой папке, только нужно найти нужный бинарник qmake (от целевой версии Qt).
Там самая большая проблема, что нам надо из билд системы получить кучу информации о проекте. А сейчас CLion такую информацию только из CMake умеет получать. Это информация нужна для корректного парсинга/резолва кода.
ещё было бы неплохо Ninja добавить. Говорят, она в некоторых случаях сильно ускоряет компиляцию больших проектов.
Да, на многих проектах сборка с генератором Ninja существенно быстрее. Но опять же — сначала надо CMake «отвязать», а дальше смотреть.
А может отвяжете так, чтобы можно было указать скрипт/несколько скриптов которые возвращают информацию в стандартном представлении?
Тогда прикрутить различные системы сборки можно будет просто дописывая эти скрипты под используемые системы сборки.
Это будут не совсем скрипты, но API для добавления других билд систем.
Тоже сойдёт, тогда жду релиза :)

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

нинзю/gn давайте чтобы с хромом работать.
Хромиум? С ним, боюсь, не только в ninja проблемы.
ну clion падает на импорте и зависает — это да. Ну вы же должны быть лучше vs, а он почти тянет проект.
Не, ну если увеличить xmx (память), то мы сможем открыть. Но проект, конечно, очень тяжелый.
Увеличивал и открывал таки, но с таким скрипом работает — при обновлении подвисает намертво. Хромиум не такой большой как кажется, там 2/3 third_party библиотеки, который нужны только по особым случаям.
Работать как-то с Хромиумом действительно очень тяжко. Для нас это хороший референсный проект. Когда там все будет хорошо, в других местах все будет просто отлично по перфомансу!
Я увеличил до xmx до 8 GB, работаю с Clang/LLVM. В принципе жить можно. Местами конечно притормаживает. Тот же QtCreator пока быстрее проект открывает, и в целом code completion шустрее работает. Но у них к сожалению очень всё сыро. Даже нормальную поддержку auto до сих пор не сделали.
Makefiles! Makefiles! Скорее бы уже. Я каждый день использую либо Go[g]Land, либо PyCharm, либо NetBeans, ибо CLion все-еще не поддерживает GNU make, и как-то становится обидно что плачу за весь toolbox, а пользуюсь только на 2/3.

Хоть какой-нибудь примерный ETA можете подсказать, когда нам уже придет счастье?
Планируем в 2018 этим заняться.
Вы про UI для pretty printers? Не добрались пока. Но вот ошибку, которая там обсуждалась, мы поправили.
Сейчас начнём потихоньку отвязывать CLion от CMake

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

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

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

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

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

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

Да, вводить какую-то свою проектную модель не планируется. Хочется именно, добавлять новое.
Новые инструменты и фреймворки — Valgrind Memcheck
Т.е. в Windows это не работает?
К сожалению, нет. И даже запланированные на 2018.x Google Sanitizers делу не помогут — они тоже не работают на Windows.
Почему к сожалению?
Ну, потому что для пользователей на Windows у нас пока хорошего решения нет.

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

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

image


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

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

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

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

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

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

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

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

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

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

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

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

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

Ну, вообще если часто в комплишене исользуется какая-то функция, она автоматически поднимается в топ в списке. Если же просто usages использовать, это, наверное, слишком сложная метрика… А smart completion не помогает (он фильтрует по типу, когда может)?
Планируется ли добавление удаленной отладки через SSH на машинах с другой архитектурой процессора, другим toolchain-ом (Raspberry PI и.т.п.)?
Сейчас есть вариант удаленной отладки через gdbserver, GDB при этом на локальной машине запущен. И скоро начнем работы по поддержке удаленной отладки, когда GDB именно удаленно запускается.

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

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

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

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

  1. Да, наверное было бы неплохо что-то такое реализовать. Есть еще несколько относительно связанных запросов: CPP-10731, CPP-8848, CPP-7388
  2. Хоть какой-нибудь можно, но хочется чтобы он работал и не втыкал хотя бы в основной массе случаев. Мы пока думаем. Нам про этот запрос часто напоминают.
Посмотрите, как сделано в Eclipse/VS/VSCode. Такого будет достаточно.
Очень плохо работает функция Evaluate и Watch в отладке, например когда из кастомного списка типа QList вызвать size() в Evaluate выдает ошибку. Это с первых версий не работает. Будет ли исправлено?
А если подключить pretty printers из Qt через .gdbinit, проблема остается?
И я, и я хочу попиариться на вас!
Кому вот CLion для МК?

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

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

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


И видео.

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

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

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

Отлично!

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

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

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

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

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

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

Полезных улучшений много, вы молодцы!
Ну вот наконец ресурсы на это появились. Спасибо)
Расширьте, пожалуйста, возможности подсветки синтаксиса. Например, вы реализовали возможность отмечать разным цветом объявление и вызов функций, но я думаю, что полезнее было бы различать функции, методы и статические методы (не отменяя положительного влияния уже сделанного изменения). Лично меня от перехода с VS на CLion останавливает в первую очередь именно эта область функционала.
Стоит, наверное, закинуть запрос в трекер.
Разделение объявления и вызовы просто существовало в платформенных общих настройках, но не было унаследовано для настроек в C++ файлах. Нас очень давно просили эту небрежность поправить. Вот, наконец, руки дошли.
Только полноправные пользователи могут оставлять комментарии.
Войдите, пожалуйста.