Как стать автором
Обновить

Комментарии 25

А есть возможность просмотра памяти, как это сделано в Visual Studio и многих других IDE?

Если не понятно, о чем речь
image
Memory View пока нет. Надеемся, что появится в 2018.x каком-нибудь.
Пройдя по ссылке, можно проголосовать. Я свой голос уже давно оставил :)

Планируется добавление Dlang?

Пока нет таких планов.

Эхх. Когда вы уже поддержку ninja прикрутите… сmake_ninja_wrapper.py не предлагать, ибо от него больше проблем чем пользы.

Пока не знаем, как порешать некоторые технические проблемы. Но раз уж начали отделение CMake от CLion, может и сможем скоро сделать.
начали отделение CMake от CLion


Надеюсь, это не ухудшит поддержку cmake проектов.
Не должно. Мы стараемся следить за этим. Наоборот, станет возможным поправить какие-то проблемы, которые в старой архитектуры не решались.
А почему комплектный дебагер с версии 2017.3 перестал вообще выводить на экран текст(printf)? Тяжело ориентироваться в таком режиме, по этому все еще пользуюсь версией 2017.2.3.
Мы не в курсе о чем речь, кажется. Какой дебагер — GDB или LLDB? Какая платформа? Можно пример и логи дебагера?

Есть такая проблема на винде, но она не сейчас появилась.
Да именно такая проблема как по ссылке, этим багом занимаются?
Это, к сожалению, не очень тривиальная проблема с pty на Windows. И появилась именно с GDB 8. fflush помогает. Хорошего решения в виде фикса пока не придумали.
qmake вряд ли будет первым на очереди. А вот что-то из makefiles, open folder, compilation database – весьма вероятно. А еще project model API, чтобы можно было плагины для любых проектных моделей любым желающим писать.

А не использовать даже под дулом пистолета RLS для Rust — это у вас принципиальное решение? А то нынче ваш плагин для Rust не способен определить и 5% ошибок, только самые тривиальные, в то время как RLS выдаёт все те же ошибки, что выдаёт компилятор.

Передаю со слов разработчика плагина:


  1. по поводу RLS (Rust Language Server) — да, это принципиальное решение, так как позволяет нам использовать полноценную инфраструктуру нашей платформы (что было бы несколько затруднительно, если бы мы просто использовали RSL). Есть соответствующее issue по данному поводу https://github.com/intellij-rust/intellij-rust/issues/964 с соответствующими комментариями. Я не большой эксперт в RLS, но судя по комментариям (в том числе этому https://github.com/intellij-rust/intellij-rust/issues/964#issuecomment-328878107) за счет этого мы имеем как минимум лучший auto completion.


  2. по поводу ошибок. По умолчанию мы действительно мало что показываем в текущий момент, в этом у RLS действительно есть преимущество (так как для этого дергается компилятор). Но это можно улучшить уже сейчас как минимум двумя способами:
    • Включить cargo check (Language & frameworks > Rust > Use cargo check to analyze code). Это external annotator, которые для ошибок просто дергает компилятор. Сооответственно, он показывает все ошибки, что может показывать компилятор. К сожалению, он не очень быстрый (собственно из-за постоянного вызова компилятора), поэтому будет тормозить на не маленьких проектах и поэтому отключен по умолчанию. В целом сделан для того, чтобы иметь такую возможность, пока мы сами не заимплементим большее количество ошибок.
    • Включить инспекцию “Experimental checks”. Показывает ошибки при вводе типов (кажется одна из самых распространненых) + добавляет несколько простых quick fix’ов. Она была отключена по умолчанию, так как могла генерировать много false positive ошибок. В данный момент мы хотим включить ее по умолчанию, так как, кажется, что большинство недоработок там было поправлено.
Фичи это конечно хорошо, но основаная проблема вашей среды — это дикие тормоза на больших проектах!!! И это кажется нужно решать в первую очередь, не знаю куда смотрят ваши менеджеры вообще, если честно. youtrack.jetbrains.com/issue/CPP-7168 youtrack.jetbrains.com/issue/CPP-8459. Каждый день у меня зависает Clion по 3-5 раз на дню, приходится его прибивать или юзать другой редактор(походу придётся перейти, раз вы никак не хотите это фиксить). Зависания до 300 секунд — это ни в какие ворота.

Проблем с производительностью на больших и сложных проектах действительно довольно много. И мы над ними работаем. Есть некоторые принципиальные ограничения платформы, которые, как выяснилось, очень критичны для C++. Именно с ними мы сейчас и работаем. Если точнее, есть большой план на этот год, как убирать фризы в редакторе. В 2018.1 уже попала часть изменений, связанная с фризами при печати в редакторе. Стало значительно лучше. Задачки, на которые Вы ссылаетесь, тоже есть в плане.
И да, менеджеров у нас почти нет, но есть команда, которой не все равно, поверьте. И мы сами сожалеем, что не успеваем быстрее такие проблемы решать.

А ещё конечно вот эта мега просто крутой баг! Очень мешает жить! youtrack.jetbrains.com/issue/CPP-5715 В кракце, у тебя 2 одинаковых файла cool_class.hpp в разных папках проекта. И при навигации из cool_class.cpp в разных папках ты попадаешь в тот, который находится в папке, которая выше по алфавитному порядку. Причём воспроизводитмость 100%. Бесит жутко, потому что в больших проектах имена классов часто повторяеются в разных папках. И это вы не можете поправить 2 года ?!!! Серьёзно? Да это любой студент поправит за 1 неделю! Дайте уже нормального леща вашим менеджерам, чтобы они фиксили боли разработчиков, которые реально пользуются вашей IDE, иначе всё больше народу уйдёт с неё на что-то другое.

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

А что с поддержкой Qt? Есть удобный импорт из проекта Qt Creator?

Qmake не поддерживается и я не уверена, что существует хороший конвертер из qmake в cmake. Есть как бы встроенная Import Project функциональность, но она, конечно, довольно базовая.

Мне иногда кажется, что лучшим решением для CLion, на текущий момент, было бы — немного притормозить с внедрением новой функциональности и в 1 релиз все силы кинуть на фикс существующих многочисленных багов в уже существующей функциональности. За последние 2 года я насоздавал в Вашем баг-трекере более 70 откровенных багов и проблем, приводящих к тому, что пользоваться той или иной функцией IDE затруднительно или невозможно. Ни один баг так и не был поправлен. Видимо это связано с «есть более приоритетные задачи». Я разрабатываю несколько кросс-платформеных приложений и у меня возникало непонимание — почему в одной и той-же версии IDE и одном и том же проекте — баги (в области работы с исходным кодом) разные. Начал изучать вопрос и понял. У Вас существует проблема — часть фиксов, которая идет с обновлением просто не применяется к старой версии. На всех 3 моих IDE CLion на разных ОС с и с разной начальной версией установки разный набор «недоисправленных» багов. Жду момента когда смогу всецело пересесть с громоздкой и неповоротливой VS и пока так и не получается…
Давайте попробуем разобраться:
  1. «Притормозить» — именно это и означают большие переработки в парсере и огромные усилия, которые затрачиваются сейчас на кардинальные изменения для улучшения перфоманса. Потому что можно было бы и дальше делать 20-30 мелких багов методом заплаток, пока все не развалиться, а можно – перерабатывать код большими кусками. Именно вторым мы и занимаемся. Возможно, «вашим» багам не везет и они не попадают в те огромные пласты, которые связаны в общее целое и закрываются пачками в каждом релизе. Если так, ты мы приносим извинения, что «ваши» баги пока не попали в наш текущий todo-список.
  2. Отсюда вытекает и проблема с обратным портированием фиксов. К сожалению, фикс, который полностью переписывает ту или иную часть подсистемы порою очень затратно, а иногда и невозможно положить в старые версии (меняется код CLion, код платформы, код других компонент). К тому же, на старых версиях почти не бывает EAP-билдов, а значит есть риск сломать что-то и он очень велик. Конечно, каждый случай рассматривается отдельно, но портирование обратно происходит в основном только в самую близкую, то есть в текущую релизную версию (то есть например, идет EAP 2018.2, а фиксы по-возможности портируются еще в 2018.1).
  3. Ну и, наверное, самое очевидное, но все же, в команде есть разные люди, отвечающие за разный функционал. Можно всех людей на языковой поддержке занять баг-фиксами по языковой поддержке, но это не будет никак мешать заниматься реализацией поддержки удаленной разработки человеку, который отвечает за эту подсистему.
Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.