Comments 21

Про assembly view — да, мы хотели это успеть к 2020.2, но отложили на 2020.3. Надеемся, получится.
Про тонких клиентов история более сложная. Есть сейчас некоторые наработки общие для всех IDE в этом направлении, и какой-то очень урезанный функционал может вскоре появится, возможно в виде какого-то плагина. Есть более глобальные и прорывные идеи, но про них пока рано даже рассказывать, не то, что eta выдавать. В общем, stay tuned!

С каждым новым релизом CLion расстраивает всё больше. С переходом на новый проект стало совсем сложно им пользоваться.


Анализ кода отваливается стабильно 2-3 раза в неделю и без перезапуска всей IDE работать отказывается.
Возможности указать кастомные инструменты для сборки глобально (для пользователя), а не в каждом проекте по новой так и не добавили( а без этого работа с compilation database превращается в бег с препятствиями( использовал бы cmake модель, но импорт завис на 1,5 часа и ничего не выдал в результате )
До сих пор нет возможности указать кастомный бинарник lldb( видимо из-за того, что интегрирован он не напрямую, а через LLDBFrontend )
На топовом на данный момент i9 IDE иногда занимает от 4 до 7 ядер полностью минуты на 2, если просто немного проскролить открытый файл.
При 2-3 открытых файлах не хватает 8Гб выделенной памяти ( суммарно ide+clangd потребляют примерно 12Гб ) для комфортной работы — иногда поиск использований символа просто валит ide полностью

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


Давайте попробуем предметно по указанным проблемам пройтись:


  • "Анализ кода отваливается стабильно 2-3 раза в неделю и без перезапуска всей IDE работать отказывается." — а можно тикет и какие-то логи? Не уверена, что мы знаем о такой проблеме.
  • "Возможности указать кастомные инструменты для сборки глобально" — действительно может быть полезно, согласна. Посмотрю, какие у нас планы. Но пока Makefile были в приоритете
  • "использовал бы cmake модель, но импорт завис на 1,5 часа и ничего не выдал в результате" — а зачем вообще делать Import, CMake проект просто открывается через top-level CMakeLists.txt, указывайте на файл в File | Open и соглашаетесь открыть как проект. работает примерно с той же скоростью, с какой этот проект собирается CMake. Ну точно не дольше.
  • "До сих пор нет возможности указать кастомный бинарник lldb" — а зачем это нужно? И про какую ОС идет речь?
  • "На топовом на данный момент i9 IDE иногда занимает от 4 до 7 ядер полностью минуты на 2, если просто немного проскролить открытый файл." — а есть возможность пошарить нам CPU snapshot посмотреть?
  • "При 2-3 открытых файлах не хватает 8Гб выделенной памяти" — можно было бы глянуть на memory snapshot и посмотреть, можем ли мы улучшить потребление памяти.
  1. Тикет не заводил, потому как каких-либо данных для повторения у меня нет, происходит абсолютно спонтанно
  2. Речь идёт именно про такое использование. Конфигурация проходит, после чего надолго виснет на "Loading cmake project". https://youtrack.jetbrains.com/issue/CPP-14139, у меня не WSL, но симтомы почти такие такие же. Прикладывал там лог с длительностью импорта 1:18
  3. Linux. Был случай, когда поставляемый lldb не мог остановиться на брекпоинте, хотя установленный системно нормально отрабатывал. Ну и просто как минимум странно и не очень очевидно почему для gdb такая возможность есть, а для lldb — нет
  4. Да, могу попробовать отловить
  5. Разве сбор memory snapshot доступен в релизных билдах? В help/diagnostic tools я указанный пункт не вижу. Как и CPU snapshot
  1. Попробуйте взять и отправить нам лог IDE, когда в следующий раз повториться. Было бы очень интересно поизучать.
  2. Увидела лог, да. Посмотрим как только сможем и постараемся отписаться по проблеме в тикете.
  3. Мы действительно по разному работаем с отладчиками. Через MI с GDB и через API c LLDB / через LLDBFrontend. Я попросила девелопера отписаться в тикете по нашим планам. К сожалению, быстро спросить не могу — человек пока в отпуске.
  4. Будет круто. Спасибо.
  5. Вот тут все инструкции
  1. Зааплоадил snapshot в скрытый комент здесь https://youtrack.jetbrains.com/issue/CPP-21641#focus=Comments-27-4310943.0-0

Вспомнил ещё одно. Generate definition не учитывает изменения в сигнатуре функции, сделанные незадолго до вызова. В результате в сгенерированном теле пропускаются noexcept, const, могут отсутствовать или иметь неверный тип аргументы. Иногда отставание может быть до минуты в больших файлах

Снэпшот посмотрим, спасибо.


Про generate definitions, интересно. Мы про такое слышали. И вот опять есть такой репорт свежий. Мы будем изучать.

Не нашёл беглым поиском подходящую issue, вот репорт из IDE, который появился во время провалившейся загрузки проекта.


https://ea.jetbrains.com/browser/ea_reports/5791997


После этого половина инклудов отмечаются как неиспользуемые, автодополнение в каких-то файлах работает, в других — нет. Переход к определению не работает нигде, всегда "Cannot find declaration to go to"

Подскажите, как можно открыть makefile проект при условии что сам makefile не в корне? (Генерируется через premake).

Открыть этот не-корневой makefile, после загрузки сделать — Change Project Root на корневую директорию. В видео, Фил ровно так и делает для postgres, посмотрите.

Да, спасибо, помогло. Проблема у меня была с тем, что toolchain для мэйкфайлов был выбран не тот.
Вопрос от забаненного гуглом новичка CLion. У меня достаточно производительный мак и очень шустрый жесткий диск. Проекты строю на «remote host», который представляет из себя докер−контейнер, запущенный на том же маке.
Обнаружил сильно раздражающий феномен. Когда я после внесения изменений в cpp−файл пытаюсь его перекомпилировать, компилируется старая версия файла. Только со второй попытки компилируется измененная версия файла.
Что−то можно с этим сделать? Например, подкрутить настройки CLion?

По идее после автосохранения (или если руками сохранить), файл должен уехать на удаленную машину. Давайте попробуем посмотреть после сохранения файла в View | Tool Windows | File Transfer. Можно с таким наверное приходить в трекер. Выглядит как бага. Ну или напишите лог из этого окна (после сохранения файла) на anastasia.kazakova @jetbrains.com

Отличный редактор, сменил с QtCreator, но:


  1. Когда появится адекватная отладка проектов на qt?
  2. Сканирование и запуск всех qt тестов, как в qtcreator, приходится либо запускать таргет конретного изменения, либо идти в creator для запуска всех тестов одной кнопкой.

Спасибо.


  1. А в чем проблема с отладкой? Скорее свего нужны pretty printers. Их можно добавить в проектный .gdbinit/.lldbinit, и GDB/LLDB соответственно будут их использовать в CLion. Бандлить с собой эти pretty printers мы не можем из лицензионных соображений.


  2. Qt tests пока действительно не поддержаны. В следующем релизе мы планируем CTest. А потом можно подумать и про Qt.


Only those users with full accounts are able to leave comments. Log in, please.
Information
Founded

1 March 2000

Location

Россия

Employees

1,001–5,000 employees

Registered

2 December 2008

Habr blog