Комментарии 25
Планируется добавление Dlang?
Эхх. Когда вы уже поддержку ninja прикрутите… сmake_ninja_wrapper.py не предлагать, ибо от него больше проблем чем пользы.
Есть такая проблема на винде, но она не сейчас появилась.
Мы начали процесс отделения проектной модели CMake от CLion
Можно ждать поддержку QMake / Qbs?
А не использовать даже под дулом пистолета RLS для Rust — это у вас принципиальное решение? А то нынче ваш плагин для Rust не способен определить и 5% ошибок, только самые тривиальные, в то время как RLS выдаёт все те же ошибки, что выдаёт компилятор.
Передаю со слов разработчика плагина:
по поводу 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.
- по поводу ошибок. По умолчанию мы действительно мало что показываем в текущий момент, в этом у RLS действительно есть преимущество (так как для этого дергается компилятор). Но это можно улучшить уже сейчас как минимум двумя способами:
- Включить cargo check (Language & frameworks > Rust > Use cargo check to analyze code). Это external annotator, которые для ошибок просто дергает компилятор. Сооответственно, он показывает все ошибки, что может показывать компилятор. К сожалению, он не очень быстрый (собственно из-за постоянного вызова компилятора), поэтому будет тормозить на не маленьких проектах и поэтому отключен по умолчанию. В целом сделан для того, чтобы иметь такую возможность, пока мы сами не заимплементим большее количество ошибок.
- Включить инспекцию “Experimental checks”. Показывает ошибки при вводе типов (кажется одна из самых распространненых) + добавляет несколько простых quick fix’ов. Она была отключена по умолчанию, так как могла генерировать много false positive ошибок. В данный момент мы хотим включить ее по умолчанию, так как, кажется, что большинство недоработок там было поправлено.
Проблем с производительностью на больших и сложных проектах действительно довольно много. И мы над ними работаем. Есть некоторые принципиальные ограничения платформы, которые, как выяснилось, очень критичны для C++. Именно с ними мы сейчас и работаем. Если точнее, есть большой план на этот год, как убирать фризы в редакторе. В 2018.1 уже попала часть изменений, связанная с фризами при печати в редакторе. Стало значительно лучше. Задачки, на которые Вы ссылаетесь, тоже есть в плане.
И да, менеджеров у нас почти нет, но есть команда, которой не все равно, поверьте. И мы сами сожалеем, что не успеваем быстрее такие проблемы решать.
- «Притормозить» — именно это и означают большие переработки в парсере и огромные усилия, которые затрачиваются сейчас на кардинальные изменения для улучшения перфоманса. Потому что можно было бы и дальше делать 20-30 мелких багов методом заплаток, пока все не развалиться, а можно – перерабатывать код большими кусками. Именно вторым мы и занимаемся. Возможно, «вашим» багам не везет и они не попадают в те огромные пласты, которые связаны в общее целое и закрываются пачками в каждом релизе. Если так, ты мы приносим извинения, что «ваши» баги пока не попали в наш текущий todo-список.
- Отсюда вытекает и проблема с обратным портированием фиксов. К сожалению, фикс, который полностью переписывает ту или иную часть подсистемы порою очень затратно, а иногда и невозможно положить в старые версии (меняется код CLion, код платформы, код других компонент). К тому же, на старых версиях почти не бывает EAP-билдов, а значит есть риск сломать что-то и он очень велик. Конечно, каждый случай рассматривается отдельно, но портирование обратно происходит в основном только в самую близкую, то есть в текущую релизную версию (то есть например, идет EAP 2018.2, а фиксы по-возможности портируются еще в 2018.1).
- Ну и, наверное, самое очевидное, но все же, в команде есть разные люди, отвечающие за разный функционал. Можно всех людей на языковой поддержке занять баг-фиксами по языковой поддержке, но это не будет никак мешать заниматься реализацией поддержки удаленной разработки человеку, который отвечает за эту подсистему.
Релиз CLion 2018.1: новые возможности из С++17, поддержка WSL, CMake Install, плагин для Rust и многое другое