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

Немного опередили, жду поддержку 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, например). Всякие рефакторинги — это уже дело десятое.
У нас пока столько задач, что не до Хаскеля. Так что если только кто-то плагин сделает

А поддержка 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. Хоть какой-нибудь можно, но хочется чтобы он работал и не втыкал хотя бы в основной массе случаев. Мы пока думаем. Нам про этот запрос часто напоминают.
Очень плохо работает функция 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++ файлах. Нас очень давно просили эту небрежность поправить. Вот, наконец, руки дошли.
Только полноправные пользователи могут оставлять комментарии.
Войдите, пожалуйста.