Pull to refresh

Comments 45

Интересно, у нового CLion такая же проблема, как и у PhpStorm с Goland'ом? А именно — после апгрейда слетают настройки цветовой схемы и шрифтов.

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

tendium
У вас случаем не x86_64 10.15+ макось с автоматическим переключением день/ночь? Тожесамое.

Мы несколько раз встречали ситуацию, когда потеря настроек происходила из-за Settings Sync плагина, когда плагин не мог залогиниться. Что-то вроде такого.

Не, у меня это случилось на маке и на винде, но автопереключения у меня нет. У меня своя кастомная тема и свои шрифты. Всё слетело и там, и там. К счастью, тема осталась на месте — пришлось возвращать.


P.S. Синхронизация выключена, так как у меня разные настройки на разных девайсах.

Заведите, пожалуйста, тикет в трекере и приложите логи IDE. Ну и настройки экспортом, чтобы мы попробовали воспроизвести.

То же самое на Ubuntu 18.04. Слетело после обновления GoLand'а.
Нет. А нужно? Я просто обратно нужный шрифт поставил :).

Лишний раз беспокоить, конечно, не хочется) Хотя и интересно разобраться все же, что именно случилось.

Когда уже добавите в отладчик просмотр данных в Qt типах? Очень не хватает этого. И таска на счет этого у вас уже ой как долго висит…

Мы не планируем писать рендеры Qt самостоятельно. А те, что поставляются с фреймворком, защищены лицензией. Но если они есть у вас на машине, то можете просто передать их отладчику через gdbinit/lldbinit — это работает для конфигов как в домашней директории, так и в директории проекта.


Таска на этот счет скорее всего будет под собой включать только какую-то помощь с поиском этих рендеров на пользовательской машине и упрощение процедуры подключения рендеров (чтобы руками в конфиги не писать).

Всё замечательно, но тормозит неимоверно, невозможно печатать. А если вырезать в буфер обмена какую-нибудь функцию, то всё может и вообще повиснуть на несколько секунд. Ну нельзя так жить.


И только не надо рассказывать про "увеличьте Xmx, отправьте дампы CPU, бла-бла-бла". Это всё повторяется из года в год, работать невозможно.

Но спасибо за то, что я худо-бедно, но наконец начал пользоваться vim+lsp

Нам очень жаль, что у вас такой опыт работы с CLion. К сожалению, проблемы действительно существуют. Пусть и не у всех пользователей и не на всех проектах. При этом хочу уверить вас, что производительность и отзывчивость редактора для нас имеют наивысший приоритет. Поэтому мы делаем довольно много для их улучшения:


  • переписываем многие тяжелые операции (требующие резолва в C++) по возможности на другой языковой движок, на базе Clang, который работает как демон
  • в 2020.2 перенесли на Clang-движок свой самый тяжелый анализ — Data Flow Analysis, что сильно улучшило его производительность
  • в 2020.3 переписали процедуру поиска юнит тестов в проекте, что существенно улучшило отзывчивость на проектах с Google Test.
  • стараемся на каждый релиз исправлять разнообразные подвисания UI

К сожалению, проблемы еще остаются. Они связаны с архитектурными решениями платформы, не слишком подходящими для C++. Для их правки у нас тоже есть идеи и внутренние прототипы. Но быстро мы их осуществить не можем, требуется время.


CPU снэпшоты и дампы от подвисаний просим у пользователей всегда, чтобы проверить, мало ли это еще какая-то проблема, о которой мы не знаем, но, например, ее можно поправить. При этом, зачастую одни и те же симптомы в разных версиях IDE имеют разные причины. Дампы тоже полезны в таких ситуациях. Так что присылайте – мы обязательно посмотрим!


Надеемся на понимание. И приносим извинения за несоответствие ожиданиям.

Подтверждаю, тоже самое. Очень часто, просто на ровном месте, зависает и необходимо ждать сек 20-30, чтобы все прогрузилось. А если окно долгое время было свернуто (несколько часов), то при разворачивании 100% будет глючить. Сам редактор очень удобный, не хочется уходить.

Если происходит подвисание UI, то IDE автоматически собирает thread dump и сохраняет их в директорию с логами. Пришлите их в нашу поддержку (clion-support@jetbrains.com), мы посмотрим в чем дело конкретно в вашем случае и постараемся помочь.

Да не надо собирать дампы, это все я виноват — я говорил, что соберу после разговора с тобой, но руки не дошли. Но я все-таки соберу.
UFO just landed and posted this here

Спасибо за поздравления.


CLion использует два языковых движка — свой более старый на Java/Kotlin, который отвечает за все кросс-проектные действия (такие как рефакторинги) и новый на базе Clangd, на который мы пытаемся перетаскивать те действия, которые возможно. На Clang пока нельзя написать индекс, который позволит делать на нем рефакторинги всего проекта, но штуки вроде подсветки, показа ошибок, автодополнения — вполне можно. К тому же, мы стали на Clang писать новые фичи, вроде parameter hints, которые показывают имена параметров в вызовах функции. С точки зрения производительности, пока явного лидера нет, просто потому что функционал не одинаков. При этом Clang вполне может работать и быстрее, и медленнее, зависит от ситуации. С зависаниями же его справляться проще — это отдельный процесс (мы используем не libclang, как Qt Creator, а Clangd, демон) и потом его можно просто перезапускать.


QML из коробки не поддерживается. Пока. Есть плагин, но он довольно сырой и не официальный. Возможно, чуть попозже мы возьмемся сами за эту задачку, но пока есть более приоритетные.

UFO just landed and posted this here

Там вроде какая-то подсветка была, но я уже давно не смотрела туда. Руки не доходят до QML у нас пока, к сожалению. А так, хочется сделать подсветку и проектный шаблон в будущем.

с удивлением обнаружил, что vim с плагином для lsp просто летает. мгновенно прыгает к определениям, находит usages, переименовывает символы, показывает диагностики. всё работает очень быстро, ничего никогда не зависает. а clion в том же проекте совершенно неюзабелен, редактор кода абсолютно неотзывчивый.


попробуйте vim или какой-нибудь другой редактор с поддержкой lsp, возможно приятно удивитесь

Здорово, что у вас получилось подружиться с редактором текста, как с IDE, но все же IDE — это не только ценный мех редактор текста, а еще и комбайн дополнительных утилит, таких как поддержка юнит-тестов, интеграция с профилировщиками и санитайзирами, интеграции с таск-менеджерами и т.д.. Безусловно настроенный vim и/или emacs будет быстрее работать с текстом(кодом), но проблема тут в слове «настроенный». Для личных нужд проблем нет, настроил, сохранил и забыл, а вот в командной разработке — это дополнительный издержки на «вхождение» в проект их хочется избежать, зачастую IDE решает этот вопрос, особенно если IDE кросс-платформенная.

Как мне кажется, полезность всех этих фич умножается на ноль, если в IDE невозможно печатать текст из-за постоянных зависаний и задержек. Нажимаешь точку – ждёшь, вставил или вырезал кусок кода – ждёшь.


Всё-таки центральная функция IDE – это именно редактирование кода проекта. Если с редактированием есть какие-то проблемы – на мой взгляд их решение должно иметь самый высшайший приоритет, и никакие интеграции с тестами и таск-трекерами никого не спасут.

Я кстати с Вами полностью согласна. Крутая машина с кучей функций — это хорошо, но при условии, что она едет) Именно поэтому отзывчивость и производительность для нас приоритетнее многих новых фич, хотя их активно от нас просят пользователи.


Возвращаясь к конкретным проблемам, а вы репортили нам дампы от подвисаний? Если да, можете указать на конкретные задачи или может вы в саппорт обращались?

UFO just landed and posted this here

Пользуюсь IDE каждый день и для работы и для своих проектов. Отличный продукт, спасибо всей команде Clion!


Так как я работаю над проектом, который содержит много кода на C++ и QML+JS, то у меня есть некоторые хотелки, многие из которых уже озвучили в этой теме:


  • gdb рендеры типов Qt (из коробки или с плагином)
  • clazy (по трекеру вижу, что в работе)
  • поддержку QML (это больше чем просто синтаксис, на самом деле и довольно большая работа)
  • поддержку vcpkg (хотелось бы конечно как pip в PyCharm, но с поправками на то, что C++ программист должен страдать). Было бы удобно как для VS Code.

Для меня лично наиболее высокий приоритет имеет поддержка QML, в первую очередь потому что довольно много кода предполагает интеграцию C++ и QML. Например, "выставление" некоторых методов классов C++ (или даже целых классов) в QML — обычная практика, в особенности если это какой-то "тяжёлый" код. Хочется, условно, иметь возможность перейти к объявлению/определению кода в C++ из QML или увидеть часть документации во всплывающей подсказке. Такого даже QtCreator не умеет.


Графический редактор, к слову, для QML вообще не нужен — просто трата времени. Язык и так декларативный и если программист умеет сворачивать блоки кода в IDE и выносить код в отдельные компоненты, то всё нормально. То что ещё как-то может пригодится — Qt Design Studio уже есть, но это больше для UX дизайнеров.

Спасибо большое! Очень рады видеть довольных пользователей.


Про QML ответила выше. Про навигацию и документацию можно завести реквесты в трекере. Надеюсь, что у нас в ближайшем будущем все же какие-то ресурсы на QML появятся.


Про рендеры тоже отвечала выше.


Clazy действительно в работе) Сложно пока предсказать, когда закончим. Там еще и вопросы по лицензии есть небольшие.


Интеграция с vcpkg может быть интересной фичей. В случае с CMake там вообще все более или менее хорошо. Но тут опять вопрос ресурсов. FYI, JFrog плагин для Conan написали сами, просто приходили консультироваться – мы с радостью помогали. Может кто-то в коммьюнити хочет написать плагин для vcpkg? Мы с радостью поможем подсказками по технической стороны)

Подскажите пожалуйста, а когда C/C++ будет в виде плагина, так же как и остальные языки? Хотя бы только в виде подсветки синтаксиса.


А то очень сложно работать в двух IDE одновременно. Это даже звучит глупо, а другого способа как бы и нет.

Нельзя C/C++ вынести просто в виде плагина "только для подсветки", надо тащить всю проектную модель, чтобы иметь возможность правильно код резолвить, понимать, откуда брать header search path, и пр. Это большая задача.


Мы рассматриваем эту возможность, но очень хочется понять, ради каких случаем мы "утяжелим" IntelliJ IDEA таких плагином. Судя по комментариям в известном тикете, довольно большое количество случаев — это Андройд разработка, которая покрывается AS в полной мере. Есть еще interop в C ради производительности, как частый случай. Почему случаи важны? Нам надо понимать, какая проектная модель будет для C/C++ в таких гибридных проектах.


Простой случай, который наверное рано или поздно будет реализован — смешанные проекты, где есть какая-то C/C++ библиотека, с CMake/Makefile файлом для сборки. Такое можно решить привнесением CLion как плагина в почти неизменном виде относительно сейчас.

Нам надо понимать, какая проектная модель будет для C/C++ в таких гибридных проектах.

В моём случае это PHP, где поддержка C идёт из коробки и нужна только подсветка, синтаксический анализ, и ничего более. Даже анализа препроцессора не нужно. И никаких CMake/Makefile и прочего. Сишные хедеры просто реализует маршаллер между языком и неуправляемым кодом.


Проблема усугубляется ещё тем, что PhpStorm/IDEA не умеют даже в примитивный language injection для C/C++ на основе Text Mate, так что кусок стандартного функционала языка просто не работает.

Text mate bundles вроде как раз работают для C/C++. Почему не умеют?


А вообще, примитивная подсветка не такая примитивная для C++. К сожалению, язык такой, что в общем то даже для подсветки может потребоваться резолв, потому что надо будет понимать каждый раз — перед нами тип или не тип.


Для таких случаев как ваш, больше бы подошел C-базовый плагин к PhpStorm и другим языкам, где на C некая низкоуровневая прослойка написана. Но тоже не понятно в общем случае, откуда мы возьмем флаги компиляции и header search paths для правильного резолва. Но мы думаем в этом направлении (да, я понимаю, что прозвучит как "лежим в сторону выхода", но нет, думаем чуть более активно), обсуждаем с коллегами из других IDE разные варианты и примеры живые, которые они знают).

Text mate bundles вроде как раз работают для C/C++. Почему не умеют?

Ну вот потому что так. В SQL умеет, в C# умеет, в CSS умеет, да во всё умеет, кроме C/C++.


А вообще, примитивная подсветка не такая примитивная для C++.

Это да. Как минимум возникают проблемы с препроцессором, т.к. для корректного анализа нужно выполнять этот препроцессинг в самой IDE. А половина правил берётся из самого компилятора, вроде PREREQ для гцц. С другой стороны — для таких ситуаций можно сделать стабы по аналогии с PHP (https://github.com/JetBrains/phpstorm-stubs), но непосредственно под каждый компилятор. Это должно решить проблемы с выводом типов.


Но тоже не понятно в общем случае, откуда мы возьмем флаги компиляции и header search paths для правильного резолва.

Можно выставлять руками, по аналогии с include paths в других языках:


Типа такого

image


А при добавлении CMake — автоматом импортировать из него пути.

Ну вот потому что так. В SQL умеет, в C# умеет, в CSS умеет, да во всё умеет, кроме C/C++.

Надо пойти в File Types в настройках и из абстрактного типа C/C++ удалить расширения C/C++ файлов. Это мешает text bundles использоваться.


Header search path это не include path. Это вообще завязка на тулчейн и где лежат библиотеки. Об этом обычно осведомлена проектная модель и это может быть довольно тяжелой настройкой. Ну разве что как-то тулчейн весь где-то указывать.

Надо пойти в File Types в настройках и из абстрактного типа C/C++ удалить расширения C/C++ файлов. Это мешает text bundles использоваться.

Да даже если удалить всё — ничего не поменяется.


Заголовок спойлера

image


Header search path это не include path. Это вообще завязка на тулчейн и где лежат библиотеки.

Ну мое дело предложить вариант решения. Разницы между этими двумя терминологиями я не представляю. Если имеется ввиду, что хедеры завязаны на директивы компилятора, то вариант решения я озвучил выше — можно организовать набор стабов под каждый компилятор.

Ну мое дело предложить вариант решения. Разницы между этими двумя терминологиями я не представляю. Если имеется ввиду, что хедеры завязаны на директивы компилятора, то вариант решения я озвучил выше — можно организовать набор стабов под каждый компилятор.

Да, спасибо за идею. Пока кажется просто, что это какой-то UI-ад выйдет) К тому же, есть еще и разные конфигурации, с разным набором компиляторных флагов и опций. Количество настроек начинает расти экспоненциально или появляется своя новая проектная модель, чего не хочется делать.

Опробовал «Code with me» — огонь фича! Правда, пока много багов и недоработок, типа редактора, который уходит в самоволку и начинает сам писать/удалять текст, и отсутствия автокомплита при написании кода.
Всё ещё всплывают проблемы с подсветкой синтаксиса: бывает, она просто исчезает из куска/файла. Есть возможность переложить подсветку простейших вещей на быстрый и надёжный движок? Чтобы хоть базовые вещи (ключевые слова, макросы, может быть переменные/функции) не становились внезапно серой массой?

Code With Me еще очень и очень сырой! Спасибо, что попробовали, и очень рады, что вам понравилось уже на текущей стадии. Проблемы и пожелания по плагину/сервису заводите в трекер, пожалуйста. Фидбека сейчас очень много и мы очень не хотели бы что-то важное потерять на данном этапе! Заранее спасибо.


Проблемы даже с подсветкой в CWM могут не воспроизводиться в обычном режиме работы и быть именно особенностью CWM. Поэтому лучше изначально именно там баги заводить.

Проблемы даже с подсветкой в CWM могут не воспроизводиться в обычном режиме работы и быть именно особенностью CWM. Поэтому лучше изначально именно там баги заводить.


Так я про подсветку отдельным пунктом, никак не связанным с CWM =)
Так я про подсветку отдельным пунктом, никак не связанным с CWM =)

Тогда в трекер CLion заведите проблему, приложив пример, логи IDE, номер версии продукта и операционной системы. Возможно, еще используемый тулчейн поможет для изучения.

Планируется ли реализация возможности запускать что-то кастомное для сборки проекта вместо CMake? Мы пишем код в Windows под macOS на C++, Obj-C/C++, поэтому в целом IDE подходит, но как вместо запуска CMake запустить наш билд скрипт я так и не понял :(
Переменные окружения, похоже, в командах сборки и деплоя сорцов нельзя использовать?

И еще я не разобрался как настроить кэш инклудов с билдера (у нас куча внешних зависимостей и их тоже хочется подтягивать — не только системные хэдеры).

Плюс нехватает какого-нибудь файла глобальной настройки — чтобы настроить его один раз и вчекинить в ветку, а он сам подтягивался у каждого разработчика. В MSVS есть Directory.Build.props, но он так себе. Мы доработали эту идею и назвали Project.Build.props — там можно один раз описать настройки для всех проектов солюшена (сборка, инклуды и т д).

В общем, не знаю просто как с кем-то из JetBrains связаться минуя багтрекер, поэтому пишу здесь. Ну и плюс вдруг такое кому-то еще интересно.

Сборка может идти не только через CMake. Во-первых, поддержаны и другие проектные модели. А главное, есть такая штука как custom build targets. Это похоже на то, что вам нужно.


Про файлы глобальной настройки я не до конца поняла детали. Кажется, что что-то придумать можно.


Можно написать в саппорт на clion-support@jetbrains.com и описать подробно use case и требования, а мы попробуем подобрать решение.

Спасибо, custom build target и правда похож на то что нужно! Ок, напишу в саппорт

Реквест #3037849. Правда, я на русском писал — надеюсь, ничего страшного :)
Sign up to leave a comment.