Comments 21
Можете дать обновление по eta следующих фич?
https://youtrack.jetbrains.com/issue/CPP-1742
https://youtrack.jetbrains.com/issue/CPP-15986
Про 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 и посмотреть, можем ли мы улучшить потребление памяти.
- Тикет не заводил, потому как каких-либо данных для повторения у меня нет, происходит абсолютно спонтанно
- Речь идёт именно про такое использование. Конфигурация проходит, после чего надолго виснет на "Loading cmake project". https://youtrack.jetbrains.com/issue/CPP-14139, у меня не WSL, но симтомы почти такие такие же. Прикладывал там лог с длительностью импорта 1:18
- Linux. Был случай, когда поставляемый lldb не мог остановиться на брекпоинте, хотя установленный системно нормально отрабатывал. Ну и просто как минимум странно и не очень очевидно почему для gdb такая возможность есть, а для lldb — нет
- Да, могу попробовать отловить
- Разве сбор memory snapshot доступен в релизных билдах? В help/diagnostic tools я указанный пункт не вижу. Как и CPU snapshot
- Попробуйте взять и отправить нам лог IDE, когда в следующий раз повториться. Было бы очень интересно поизучать.
- Увидела лог, да. Посмотрим как только сможем и постараемся отписаться по проблеме в тикете.
- Мы действительно по разному работаем с отладчиками. Через MI с GDB и через API c LLDB / через LLDBFrontend. Я попросила девелопера отписаться в тикете по нашим планам. К сожалению, быстро спросить не могу — человек пока в отпуске.
- Будет круто. Спасибо.
- Вот тут все инструкции
- Зааплоадил 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"
Приложил файл лога сюда https://youtrack.jetbrains.com/issue/CPP-20216#focus=Comments-27-4326591.0-0
Подскажите, как можно открыть makefile проект при условии что сам makefile не в корне? (Генерируется через premake).
Обнаружил сильно раздражающий феномен. Когда я после внесения изменений в cpp−файл пытаюсь его перекомпилировать, компилируется старая версия файла. Только со второй попытки компилируется измененная версия файла.
Что−то можно с этим сделать? Например, подкрутить настройки CLion?
По идее после автосохранения (или если руками сохранить), файл должен уехать на удаленную машину. Давайте попробуем посмотреть после сохранения файла в View | Tool Windows | File Transfer. Можно с таким наверное приходить в трекер. Выглядит как бага. Ну или напишите лог из этого окна (после сохранения файла) на anastasia.kazakova @jetbrains.com
Отличный редактор, сменил с QtCreator, но:
- Когда появится адекватная отладка проектов на qt?
- Сканирование и запуск всех qt тестов, как в qtcreator, приходится либо запускать таргет конретного изменения, либо идти в creator для запуска всех тестов одной кнопкой.
Спасибо.
А в чем проблема с отладкой? Скорее свего нужны pretty printers. Их можно добавить в проектный .gdbinit/.lldbinit, и GDB/LLDB соответственно будут их использовать в CLion. Бандлить с собой эти pretty printers мы не можем из лицензионных соображений.
Qt tests пока действительно не поддержаны. В следующем релизе мы планируем CTest. А потом можно подумать и про Qt.
CLion 2020.2: поддержка проектной модели Makefile, больше C++20 и не только