Pull to refresh

Comments 63

По поводу новой фичи Clangd: он у меня течёт в sles, так что пришлось отключить.
Касательно производительности: на больших файлах всё ещё лютые фризы, надеюсь поправите к следующему релизу.

А можно чуть больше деталей про утечки: suse linux? Как именно видно утечки, какие логи/дампы смотрите? Какие-то конкретные сценарии работы с IDE при этом или просто открываете проект и более особо ничего? Движок на clangd пока экспериментальный, ваш репорт будет очень полезен, наверняка мы что-то упустили.

Про фризы — вы CPU снэпшоты нам не репортили? Просто понять, это что-то новое или просто еще непофикшенное старое. Если репортили, можно номер тикета напомнить.

К сожалению, сейчас нет доступа к машине и проверить подробности утечки не могу. Помню что через несколько сборок проекта (через make) cland начал есть слишком много памяти. Отключение помогло.
Фризы точно не новые, потому что мучаемся с этим достаточно давно. Репорты емнип не отправляли, ибо там похожих тикетов и так много. Файл большой (30к строк), может проблема в макросах.

А «слишком много» — это сколько? И что при этом открыто в редакторе? Попробую пояснить вопрос — 1.5-2Гб в некоторых случаях, при нескольких больших открытых файлах в редакторе, это норма.
~1гб, но этого оказалось достаточно, чтобы забить до упора память моей машины.
> при нескольких больших открытых файлах в редакторе
Проект как раз был небольшой, и файлов крупных не было. Максимум 500 строк.
Инклюдов прилично (llvm, clang-lib), считаете в этом дело? Если так, то 2гб «хватит всем»?
Возможно. А проект случайно не OS? Посмотреть не получится?

В целом, стоит понять, там память течет или ее просто (почему-то) много требуется для работы clangd. К сожалению, в экспериментальной версии пока не много вариантов посмотреть какие-то логи и всякую отладочную инфу. Завтра командой подумаем, как вообще нам такое более удобно диагностировать и какие логи от вас нам могут помочь.
Чтобы избежать ложных срабатываний, алгоритм отключается автоматически для очень коротких имен (менее 3 символов).

А можно все же включать для переменных с названиями типа
vx, vy, vz
x1, x2, x3
?

Например, если имя переменной соответствует (.+)[xyz]|[xyz](.+)?
Можно, наверное, но логика эвристик очень сильно усложнится или будет много ложных срабатываний. Так что пока выключены такие ситуации. Мы обсудим, спасибо!
UFO just landed and posted this here
В любой непонятной ситуации добавляй крутилку в настройки!
Как показывает практика — это не работает. Ибо очень, очень мало людей трогают настройки если и без этого «всё работает».
Планируется ли что-то делать с инспекциями кода, а точнее с тем, что на больших файлах (да практически любой файл из LLVM) во время запуска инспекций кода помечается как «Too complex». Особенно заметно на больших header-only библиотеках. Тикет в багтрекере висит, но непонятно, планируется ли это фиксить.
Планируется, конечно) Если коротким ответом.

Если чуть более вдаваться в детали, то такая ошибка выдается вполне конкретной инспекцией, а не всеми, – Data Flow analysis. Ее можно отключить, если ошибка сильно мешает.

Но вообще DFA правда может быть очень сложным. Хотя, конечно, бывает, что просто из-за проблем в парсере такая ошибка в инспекции. Проблемы парсере — у нас в приоритете, но за этой ошибкой too complex может скрываться столько разных случаев / причин / проблем, что вот взять и починить все и сразу пока не получается.
Ну просто насколько я помню в тикете отписали, что там есть какие-то ограничения движка. Если отключаете проверку из-за того, что проверка может занимать слишком много времени, то я бы согласился на Opt-In опцию с предупреждением, что это может сильно замедлить анализ. Так как вполне вероятно, что у меня на компьютере довольно неплохой процессор с достаточным даже для CLion обьёмом оперативной памяти, что я готов пойти на такие жертвы ради инспекций :-)
Дело не во времени анализа. Too complex означает, что CLion не смог провести DFA из-за сложности кода. Если видите такое уведомление, это как раз и есть предупреждение, что может надо отключить инспекцию.
Анастасия, а можно чуть подробнее о причинах побудивших задействовать clangd?
Спрашиваю потому, что давным-давно (кажется в FB) я советовал вам идти этим путем, а вы не соглашались…
Не совсем правда, что мы не соглашались.
  1. Мы всегда говорили, что есть причины, почему clang не был выбран изначально (исторические платформенные ограничения).
  2. Есть (до сих пор) сомнения, что на clang можно решить все необходимые для IDE задачи, потому что это компилятор и он архитектурно предназначен для других задач.
  3. Не понятно пока, получится ли на нем сделать global refactorings и прочие умные штуки на всем проекте, а если и получится, то будет ли это достаточно быстро работать.

Но мы в общем то никогда не скрывали, что смотрим на разные другие решения для парсера и clang одно из них.
А сейчас просто нашлись ресурсы, чтобы этим заниматься. + Пришло понимание, как бы подружить clang и нашу платформу. + Мы научились дружить clangd и наш собственный парсер, чтобы они работали одновременно и не мешали друг другу. В общем сложилась благоприятная обстановка, чтобы что-то реально попробовать и показать пользователям. Надеемся, что получилось неплохо.
Насколько это экспериментальное решение станет постоянным, я пока не могу сказать. Время покажет.

cquery рассматривали как вариант?

Мы много чего рассматривали как варианты. До серьезного рассмотрения и proof of concept дошли не многие опции)
Слишком общий вопрос) Штука хорошая, а насколько применима будет успешно в наших условиях — зависит от того, что мы от LSP ожидаем. С clang было решено работать через clangd/LSP, в общем же LSP в CLion никто пока не обсуждает.
Для того, чтобы эффективно использовать clang в IDE (как парсер) — clang надо правильно готовить и патчить. Как правильно написала Анастасия, кланг — это, в первую очередь, компилятор. И ведёт он себя с кодом как компилятор, а не как IDE — более строго. И работает он, мягко скажем, не быстро. А чтобы заставить работать быстро — надо колдовать. Да и после колдовства (если не лезть глубоко в реализацию парсера) некоторые фишки просто не будут работать. Например, о фичах типа «создать декларацию функции из определения» или «создать декларацию из использования» можно будет забыть — кланг для таких кусков кода просто не построит адекватную AST (код для него, как компилятора, будет невалидный). Про адекватную работу код-коплита внутри шаблонов тоже можно будет забыть, передав привет двухфазному парсингу. В общем, дружить clang и IDE — весело. И больно.

Обновился, радуюсь. Вопрос возник по выравниванию кода после вложенных циклов.
Пишу что-нибудь такое


    for (int i = 0; i < 2; ++i)
        for (int j = 0; j < 3; ++j)
            for (int k = 0; k < 3; ++k) {
                int s1 = i * i;
                int s2 = j + k;
            }
            std::cout << "incorrect indentation\n";

и после этого выравнивание идет по закрывающей фигурной скобке. Code->Reformat Code приводит все в порядок, то есть строка после цикла будет с тем же отступом, что и внешний for. Вставка пустой строки не помогает.

Похоже на багу. И кажется, оно так работало и в форматере на парсере, и в новом форматере на лексере( Занесли в трекер OC-17542
Я не знаю как правильно сформулировать вопрос, по этому попробую описать ситуацию…
Существует разрабатываемый энтузиастами плагин для IDEA I-Pascal, для поддержки языка pascal соответственно. При этом он строится на проектной (модульной) модели IDEA. Но на самом деле проекты pascal очень близки по своей структуре к C++. В них включенные в проект файлы определяются файлом системы сборки, там же указываются дополнительные зависимости, параметры. В Pascal так же активно применяется препроцессор (не такой функциональный как c++, но так же влияющий на поведение кода, его разбор, анализ и рефакторинг).
Сейчас вы активно развиваете проектную модель и я хотел бы спросить — попадут ли эти наработки в основную IDEA и станут ли доступны для написания языковых плагинов к языкам с похожим поведением? Конкретно — построение структуры проекта из условной сборочной системы и обслуживание препроцессора?
Пока не знаю, что Вам ответить. Это две разные задачи — сделать API для проектных моделей в CLion и перенести его в IntelliJ IDEA (тут просто исторически CLion отдельно развивается, поэтому это не просто). Но если, например, делать плагин из CLion к IntelliJ IDEA, то придется в любом случае переносить. Так что есть такая вероятность. А вот каких-то оценок по времени скорее нет.
Я правильно понимаю, что CLion функциональность не доступна из Idea в виде плагина (т.е. ситуация ближе к .NET/Rider чем, например к go/javascript?).
CLion действительно существует только как отдельная IDE, а как плагин — нет. Это не то, чтобы принципиальная позиция. Просто так сложилось исторически, а сейчас кажется не самой приоритетной задачей, при том, что технических вопросов/сложностей там много, а ресурсы ограничены.
Позиция понятна и мне кажется разумной. Пусть уж лучше будет один хороший продукт для работы с C++ чем два плохеньких. Просто хотелось уточнить. Спасибо за ответ.

Кстати еще вопрос. Последний раз когда пробовал что-то делать с Arduiono в Clion — интеграция была слабовато. Есть ли это направление в каких-нибудь roadmaps?
Embedded направление достаточно приоритетно. Но конкретных задач пока не поставлено, там сначала надо решить пачку общих задач по отладчику: memory view сделать (он в процессе), hex view переделать (текущее решение нам не очень нравится и потому по умолчанию не включено), и тп.

Люди вроде пользуются Platform.io вполне успешно для Arduino + CLion. Там есть некоторая интеграция.
Существует средний-большой проект с многими десятками Makefiles, вызывающие друг-друга и с десятками способов/параметров как его строить на все случаи жизни. Менять их на Cmake никто не собирается, т.к. все работает, а Cmake у нас никто не знает.

Импортирую новый не-Cmake проект, как советует документация, создается cmakelists; попробовал также compilation database. В обоих случаях все вроде работает (ок, не могу скомпилировать изнутри, пишу руками «make ...» в шеле, переживу, потом добавлю макро). Рефакторинг и навигация вроде работают, и уже хорошо. Довольный иду домой.

На следующий день обновляем репу и видим, что коллеги за ночь добавили Х новых директорий и файлов с кодом. В уже созданный cmakelists они сами не попадают и clion начинает грязно ругатся на код который иx использует, не находит новые инклюды итд.
(Вроде в 2018.2 хотя-бы инклюды вроде должны были работать? Или только из уже известных директорий?)

Как вы предлагаете работать в таком случае?

После каждого git pull импортировать проект с начала, стирая старый cmakelists?
Вручную добавлять новые директории каждый раз, выискивя их по одной?
Всегда гнатъ make с генерацией новой compilation database и опять открывать по-новой?

Вы понимаете, что все эти методы не масштабируются и уважающие свое время люди не будут это все время делать?
Я пропустил какой-то метод работы с такими проектами, который все таки оправдает переход на clion?

Если способ есть, рекомендую подробно описать его в доках, т.к. терпение и время находить его самим есть не у всех. Я, например, пока что плюнул и вернулся к бесплатному эклипсу, который сам находит все изменения (у эклипса свои проблемы, конечно).
Я пропустил какой-то метод работы с такими проектами, который все таки оправдает переход на clion?
Да, пропустили. Потому что это не в CLion'е должно быть.

У нас, к примеру, вообще своя собственная распределённая система сборки. Нужно было всего лишь научить её порождать CMake-проекты и поддерживать их и всё. Но это только вы можете сделать.

Если у вас Makefiles вообще без всяких ограничений, то это, строго говоря, не делается в принципе: Makefile в принципе не даёт ответа на простой вопрос «а какие, собственно, файлы входят в ваш проект».

Но в это я не верю. Обычно в проекте есть какая-то дисциплина, которая позволяет сделать соотвествующий конвертор.

А вообще, похоже, CMake — это будущее. Уже и Visual Studio с ними научился работать и даже поверх них свою систему управления пакетами получил и всякие проекты нативно его поддерживают. Так что учить придётся.

Мне лично немного грустно, так как CMake — тот ещё кусок… добра. Но лучше уже CMake через разброд и шатание, когда в каждом проекте своя система сборки.

Я, например, пока что плюнул и вернулся к бесплатному эклипсу, который сам находит все изменения (у эклипса свои проблемы, конечно).
К эклипсу у нас тоже плагин, так как его способность находить изменения… ограничена, да…
Все верно, но «все работает и так», значит пока менять систему сборки никто не будет. Мой вопрос был с позиции, что такой раскад — аксиома, и в данном проекте не меняется.
Я не говорил, что согласен с этим — но тут так заведено ©.

Makefiles вполне (иногда — на основании параметров командной строки) определяют какие файлы когда использовать для билда, а также из какой суб-директории брать версию под конкретную железку.
И я не говорил, что эклипс все правильно парсит — но он смотрит, как я понимаю, на все дерево и пытается резолвить из всех файлов вообще.
И я не говорил, что эклипс все правильно парсит — но он смотрит, как я понимаю, на все дерево и пытается резолвить из всех файлов вообще.
Правильно. Но в нашем случае он пытается затащить себе все исходники всего-всего-всего, несколько часов грузит всё это, сжирает 64GB оперативки и умирает.

Так что в любом случае нужен плагин.
Все верно (правда иногда спасают фильтры директорий).
Но это — в корпоративный блог Эклипса :-)
А тут мы хотим что-то лучше, чем эклипс.
А тут мы хотим что-то лучше, чем эклипс.
Что лучше, чем экслипс — это среда, понимающая разные види проектов. CMake, Automake, Bazel, etc.

Но «голый» make — слишком низкоуровневая штука, чтобы оттуда выудить нужную информацию…
Начнем с вводной, что CLion для работы всегда нужна хоть какая-то проектная модель, описывающая проектные файлы, связи между ними, флаги там всякие и пр. Вся эта информация нужна для резолва. Поэтому в целом, конечно, ситуация, что используется проектная модель А, а для CLion из нее генерируется проектная модель B, и при этом другие члены команды в проектную модель А часто вносят значительные изменения она не самая удобная. В проект ведь могли добавить каких-то новых файлов, никак не связанных и не используемых в предыдущих, новых флагов, и пр. и IDE надо об этом как-то узнать. То есть такие изменения должны отразиться в проектной модели B.

Теперь больше конкретики по вопросам:

На следующий день обновляем репу и видим, что коллеги за ночь добавили Х новых директорий и файлов с кодом. В уже созданный cmakelists они сами не попадают и clion начинает грязно ругатся на код который иx использует, не находит новые инклюды итд.
(Вроде в 2018.2 хотя-бы инклюды вроде должны были работать? Или только из уже известных директорий?)

Если новые директории попали под project root и если новые файлы включены в старые (которые уже расцененные CLion-ом как проектные) файлы посредством директивы include, то новые файлы будут расценены как проектные автоматически. Все должно работать в такой ситуации. Если это не так — это бага, пишите тикет в наш трекер. Мы вот только что попробовали у тебя добавить новую директорию с файлами под project root — все заработало и для CMake, и для compilation database.

Compilation database при этом кажется более легко поддерживаемым и точным способом получения допустимой CLion-ом проектной модели, чем Import Project, который генерирует CMake проект. Мы к тому же думаем, как инкрементальный аптейт в его случае ускорить.
Спасибо за ответ, попробую в следущий раз отловить больше подробностей.

Compilation database при этом кажется более легко поддерживаемым и точным способом получения допустимой CLion-ом проектной модели, чем Import Project, который генерирует CMake проект. Мы к тому же думаем, как инкрементальный аптейт в его случае ускорить.
т.е. вы да предлагаете
Всегда гнать make с генерацией новой compilation database и опять открывать по-новой?
Попробую понятъ или так можно работать постоянно…

Вопрос о теории авто-резолва:

Если начали с:
project123
....src
........dir1
............file11.c
............file11.h

Это попало в CLion.
Потом репа обновилась до:
project123
....src
........dir1
............file11.c
............file11.h
............file12.c
............file12.h
.......dir2
............file21.c
............file21.h

Также старый file11.c заинклюдил новые file12.h и ../dir2/file22.h

Как я понимаю, все 3 .h файла найдутся и распарсятся? или file21.h не найдут, ибо из неизвестной директории?
А как насчет новых file12.c и dir2/file21.c?
dir2 не под project root, а глубже — значит его содержимое без моей помощи (или нового Compilation database) никогда не найдут?
Мне кажется, поиск новых директорий и файлов должен быть рекурсивным всюду, а не только из project root. Есть причины так не делать?
(можно добавить диалог со списком ново-найденного, где можно выбрать что взять в проект, а что выкинуть; результат выбора где-то запомнить, чтоб не спрашивать в следующий раз; я не утверждаю, что это легко хорошо сделать :-))
Поиск, конечно, рекурсивный, по файлам в дереве под project root. Все должно находиться в вашем случае.
Не найдутся те файлы, которые за пределами дерева под project root. Это как раз специально, чтобы не лезть с рефакторингами во всякие библиотеки, которые где-то сбоку проекта лежат.
Согласен.
Проверю, у меня сложилось впечатление, что именно в похожем случае не нашлись новые файлы овсем. Если повторю, открою баг.
Спасибо!
Хорошо бы пример нам показать. Может, я что-то упускаю в вашей конфигурации.
Без проблем, как только индусы коллеги накоммитят еще, проверим. Возможно я ошибся, или не дождался пока все распарсится в тот раз.
Файле никакие прислать не смогу, все секретно. Но если удастся повторить на синтетическом примере — пожалуйста.

Другой вопрос: сделал Compilation database для двух разных проектов. Оба открылись в CLion, но в одном все файлы показаны, как в оригинальном дереве (как надо), а в другом — все в одном длинном однородном списке (== невозможно ориентироватся и не понятно как и где потом можно создавать новые).
В обоих проектах файлы сидят в похожих, достаточно глубоких структурах директорий (т.е. принципиальную разницу не вижу).

Думаю, виноваты разные стили Makefiles (а не CLion). Есть идеи на что где смотреть, чтобы это починить? Я пропустил какую-то опцию CLion чтоб он сам файлы как-то рассортировал по path?
Попробуйте изменить project root.

Например,
Если у меня структура:
папка 1
… файлы проекта
… папка 2
........compilation database
и файлы проекта в папке 1, а json файл, который я открываю в папке 2, то все файлы окажутся в одном длинном списке и CLion будет считать именно папку 2 (где лежит compilation database файл) проектным рутом. Tools | Compilation Database | Change project root, указываем папку 1 и наступает счастье.

Похоже на ваш случай?
Точно, он самый, спасибо!
Вот это тех. поддержка :-)
Думаю, стоит добавить замечание об этом в доки. Там уже написано как менять project root, но не написано зачем это надо.
Спасибо, я передам техническому писателю ваш комментарий.
Да, полезно, рекомендую всем. Еще появилась подробная статья (на английском) про работу с Makefile проектами при помощи Compilation Database:
blog.jetbrains.com/clion/2018/08/working-with-makefiles-in-clion-using-compilation-db.

Что-бы строить проект, добавляем External Tool с, в котором даем командную строку нашего make, добавляем туда Output Filter, чтобы ошибки подчеркивались (и по ним можно было переходить на нужную строчку в файле с ошибкой), уговариваем наш компилятор выдавать ошибки с полным путем до файлов (например, "-fdiagnostics-absolute-paths" для clang), т.к. при дефолтном относительном пути CLion [пока?] не может найти их сам (https://youtrack.jetbrains.com/issue/IDEA-197135), если проект на Compilation Database.
Теперь, если не забывать делать ״Tools->Compilation Database>Reload Compilation Database Project״ при каждом значительмом изменении структуры проекта, уже можно работать.

Возможно не помешает статья с переводом той статьи на русский (можно даже с моими добавками про External Tool выше) — если кого-то еще это интересует.
Теперь, если не забывать делать ״Tools->Compilation Database>Reload Compilation Database Project״ при каждом значительмом изменении структуры проекта, уже можно работать.

Вроде почти запилили автоматический reload. Попробуем после тестирования померджить в 2018.2. Но в 2018.3 уже точно появится!
Это в процессе. Думали успеть прототип показать в 2018.2, но не успели. Целимся в 2018.3 сейчас

Нет в жизни счастья, с одной стороны clion с rust плагином, с другой qt creator с поддержкой .ui файлов, qt документации и стилей из clang-format

Кстати про Rust обновление мы отдельный пост написали.

qt документации

В смысле именно по Qt встроенная документация?

стилей из clang-format

Это мы давно планируем сделать. Может, в 2018.3 что-то успеем.
В смысле именно по Qt встроенная документация?

Да, документация пример которой можно увидеть здесь: http://doc.qt.io/
Поставляется с Qt (для linux часто отдельным пакетом), ее можно посмотреть
либо в отдельном приложении (Qt assistant) или просто нажав F1 на классе в Qt Creator.

Ага, поняла. Согласна, было бы удобно. Даже вот такая общая задачка под это есть в трекере, но руки пока не дошли.
Странно, после апдейта Pycharm и Clion видят проект из python и c файлов как одно целое, что ведёт к незначительным ошибкам. Ну и набор вкладок для редакторов теперь один, что очень неудобно.
Не очень поняла, если честно, что имеется в виду. Можно чуть поподробнее?

проект из python и c файлов как одно целое

А это на самом деле один проект?

набор вкладок для редакторов теперь один

Можно скриншот приложить? Я, к сожалению, не очень поняла, про какие вкладки речь.
Да, я несколько сумбурно объяснил: у меня один проект содержит C и Python код в одной директории. Теперь, когда я открываю Pycharm, я получаю:
Cannot determine module type («CPP_MODULE») for the following module:

Вдобавок, если открыть несколько файлов в соответствующем редакторе, например, main.c в Clion, а потом закрыть сам редактор и открыть тот же проект в Pycharm, то я снова получу main.c. Раньше я мог работать отдельно с .py и .c файлами, а теперь получается каша. Я не профессиональный программист и не работаю с IDE ежедневно, так что могу что-то упускать.
Более или менее замкнутый проект, который мы сможем у себя открыть. При этом он может ничего не делать, кроме как демонстрировать проблему.
Не подскажете, а есть ли вариант в CLion полностью отключить уведомления о том, что в коде есть какие-то ошибки, но оставив при это автодополнение, переход к обьявлениям функций и так далее? просто чтобы в IDE красным цветом не выделялось то, что парсер не смог распарсить (конечно я понимаю, что в данном случае часть невалидного кода тоже перестанет подсвечиваться красным). Причина — слишком большое количество красного кода на моём проекте.
Красный код отключить нельзя. Это весь на самом деле, не просто так красный код, а звоночек, что вообще весь code insight будет не правильно работать. И то же автодополнение, и навигация.

А много красного кода на какой версии/платформе? 2018.2 с clangd включенным пробовали?
Sign up to leave a comment.