Основной целью этого релиза было, как бы пафосно это ни прозвучало, качество. Мы решили сфокусироваться на проблемах, которые давно беспокоят наших пользователей, — в первую очередь, производительность и отзывчивость редактора, а во вторую — баги, недоделки и очень востребованные, но отсутствующие возможности.
Для начала, коротко о самом главном в этом релизе:
- Улучшения быстродействия и отзывчивости редактора, в первую очередь автодополнение, реализованное в нашем движке на базе Clangd.
- Ninja-генератор в CMake, настройки CMake по умолчанию и другие улучшения проектной модели.
- Обновления в интеграции с отладчиками.
- Новое действие для переключения между заголовочными и сорс-файлами.
- Более точный анализ кода: новая проверка для виртуальных функций, а также проверка правописания в CMake и в комментариях Doxygen.
- Поддержка концептов из стандарта C++20.
- Метрики покрытия кода.
- WSL2, правила форматирования и именования от Microsoft, обновления VCS поддержки и многое другое.
Ниже поговорим подробнее, но если вы готовы попробовать уже сейчас, то заходите и скачивайте билд с нашего сайта. Как обычно, доступна бесплатная пробная версия на 30 дней.
Быстродействие редактора
Судя по статистике, которую соглашаются нам присылать многие наши пользователи, самое часто используемое действие в CLion — это автодополнение. Именно на нем мы решили сосредоточить внимание в этом релизе, чтобы сделать его более отзывчивым. Для этого мы добавили к уже имеющимся в IDE «поставщикам» автодополнения еще один, на базе Clangd. Суть в том, что все поставщики работают параллельно, и, как только готовы первые результаты, CLion показывает раскрывающийся список вариантов, продолжая по мере надобности подгружать остальные варианты.
Конечно, мы захотели понять, дает ли преимущества такой гибридный подход. Замеры показали, что на простых проектах скорость собственного поставщика CLion и поставщика на основе Clangd отличаются не сильно. А вот на сложных проектах, таких как LLVM, Qt, Boost, Eigen, первые сто результатов от Clangd появляются существенно быстрее. Судите сами:
Подробнее о замерах — в отдельной статье в англоязычном блоге CLion.
Среди других значимых улучшений стоит отметить платформенное ускорение времени запуска IDE. Оно достигнуто за счет параллелизации многих процессов на старте, реорганизации классов, загружаемых на старте, оптимизации загрузки шрифтов на macOS. Конкретные числа для ускорения зависят от настроек окружения, машины, платформы и других факторов.
В CLion, к нашему большому сожалению, до сих пор встречаются подвисания пользовательского интерфейса. Мы стараемся сгруппировать их по исходной проблеме и исправлять одну проблему за другой. Так, в этом релизе мы исправили подвисания в случаях открытого окна использований (Usages View), при переходе на декларацию, при переименовании директивы #include, при использовании «хлебных крошек» и safe delete, а также в других случаях. Подвисания пользовательского интерфейса остаются самой актуальной для нас проблемой, так что эту работу мы обязательно продолжим и в следующих релизах.
Ну и, наконец, ускорения рефакторинга Rename. Этот рефакторинг умеет переименовывать не только использования имени в коде, но и в строковых литералах и комментариях. Но не всегда это нужно, а поиск имени раньше осуществлялся до того, как пользователь IDE укажет, какие именно использования хотелось бы переименовать. Это приводило к большим задержкам при поиске популярного имени. Теперь же можно сначала выбрать поиск только по коду, а уже потом запустить сам поиск. Для этого в настройках Settings/Preferences | Editor | General | Refactorings надо отключить “Enable in-place mode”. В этом случае при вызове рефакторинга (Shift+F6 по дефолту на Windows/Linux, ?F6 на macOS), CLion сначала сразу откроет диалог Rename, в котором можно указать параметры поиска:
Улучшения проектной модели CMake
Тут многие из вас наверняка ждали анонс поддержки Makefiles. Но пока что доступен только полуавтоматический подход к их интеграции через compilation database. Более нативная поддержка по-прежнему в разработке, но в этом релизном цикле мы сильно продвинулись вперед и имеем все шансы показать новую поддержку к следующему релизу 2020.1, где-то в конце марта 2020 года.
Зато мы сделали самую долгожданную возможность в поддержке CMake — возможность указать любой генератор CMake, в том числе столь ожидаемый пользователями генератор Ninja! Раньше мы использовали Makefiles и похожие на него генераторы, так как парсили результирующие файлы (если точнее, это были -G “CodeBlocks – Unix Makefiles”, а на Windows -G "CodeBlocks – MinGW Makefiles" и -G "CodeBlocks – NMake Makefiles"). Теперь можно указать любой генератор в профиле CMake в CLion:
Это возможно только при использовании CMake версии 3.15 и выше, так как реализовано через CMake File API, и работает на всех платформах, в удаленном режиме, для WSL/WSL2.
Замечу, что такие генераторы как Xcode и Visual Studio являются мульти-генераторами, то есть генерируют файлы для всех типов сборок (Debug, Release и т. п.), но CLion для индексирования и сборки будет использовать только тот тип сборки, который указан в профиле CMake.
В этом релизе также появились настройки CMake по умолчанию. Это значит, что для всех новых проектов в CLion вы можете использовать одни заранее заданные настройки, такие как генератор CMake или директория для генерации CMake. Настройки можно указать в File | Other Settings | Settings for New Projects…
Из важных улучшений проектной модели CMake еще стоит указать возможность перезагружать валидные конфигурации, даже если в проекте присутствуют другие невалидные. Это может быть полезно, если у вас настроено несколько удаленных конфигураций, которые на данный момент недоступны, но хочется перезагрузить хотя бы локальные конфигурации.
Обновление интеграции с отладчиками
В отладчиках мы решили починить те проблемы и недоделки, которые беспокоят наших пользователей больше всего. Во-первых, CLion теперь читает .gdbinit/.lldbinit из директории проекта. Это полезно, если хочется какие-то настройки отладчика кастомизировать или добавить pretty printers, но только для конкретного проекта. Ранее приходилось эти настройки указывать в конфигурационных файлах отладчика в пользовательской директории. Теперь можно настраивать эти параметры специфично для проекта. Но, чтобы это заработало, надо разрешить такое поведение в самом отладчике в настройках на уровне пользовательской директории (читайте, как это сделать для GDB и как для LLDB).
Интеграция с LLDB доступна на Linux и macOS. В новом релизе мы проадейтили встроенный LLDB до версии 9.0, а заодно глобально пересмотрели все встроенные pretty printers. Благодаря этому существенно улучшилось представление стандартных контейнеров на обеих платформах. Подробные сравнительные таблички можно посмотреть в нашем англоязычном блоге. Стоит отметить, что на платформе macOS, библиотека libc++ обрабатывается гораздо лучше, чем libstdcxx. Это вроде бы соответствует популярности данных библиотек на этой платформе, но если вы используете libstdcxx на macOS, пожалуйста, расскажите в комментариях поподробнее о таких случаях.
В CLion сейчас существует несколько вариантов удаленной работы с проектом и отладки. От полностью удаленного варианта, когда и сборка, и отладка проекта происходят на удаленной машине, до вариантов, когда удаленно происходит только отладка проекта. Вот именно для второго случая мы добавили еще одну конфигурацию в CLion — Remote GDB Server. В отличие от имеющейся уже давно GDB Remote Debug (да, с названиями у нас не задалось, согласны), в новой конфигурации CLion сам собирает проект (возможно, при этом вам надо настроить параметры кросс-компиляции), загружает исполняемый файл на удаленную машину и запускает вашу программу под указанным gdbserver. Старая конфигурация больше теперь подходит для сложных вариантов, когда код на одной машине, сборка на второй, а отладка на третьей. Или если невозможна кросс-компиляция.
Go to Header/Source files
Да, это случилось! Мы наконец добавили отдельное действие для переключения между заголовочными и сорс-файлами. В чем же главное отличие от старого платформенного Go to Related Symbol? Дело в том, что, будучи общим платформенным действием, Go to Related Symbol старается быть очень точным и подобрать один самый верный вариант. Это и долго, и не всегда правильно в случае C++. Новое действие Go to Header/Source ведет себя иначе:
- Если за 500 мс не находится один единственно верный вариант, то появляется выпадающий список подходящих вариантов, из которых пользователь может выбрать наиболее подходящий.
- Если пользователь уже переходил из этого файла, то файл, куда он переходил, будет вверху списка.
- Дальше в списке будут файлы из этой же директории с совпадающим именем.
- И затем уже будут идти результаты поиска по сопоставлению деклараций и дефиниций.
Стоит отметить особенность поиска (так как с ней уже встречались наши пользователи) — поиск сейчас ведется по непосредственно включенным/включающим файлам. Это временное ограничение, которое необходимо, чтобы не путать символы с одинаковыми именами из разных таргетов.
Анализ кода
В анализаторе кода в CLion появилась новая проверка. Она отлавливает ситуации, когда виртуальные функции вызываются из конструкторов или деструкторов. Почему это плохо, уже много где обсуждалось. Теперь и CLion предупреждает о таких случаях:
Spell Checker — неотъемлемый компонент интегрированной среды разработки. Все мы делаем ошибки в правописании, а потом нашим коллегам тяжело читать код и комментарии. Поэтому хорошо, когда IDE подсвечивает такие ошибки. В этом релизе мы включили проверку правописания в файлах CMake и комментариях документации формата Doxygen:
Меньше ошибок правописания — более читаемый код!
Концепты из C++20
Наша команда вкладывает сейчас большие усилия в языковой движок на основе Clangd. А мировое сообщество C++ активно развивает Clang. В этом релизе мы объединили усилия — взяли экспериментальную ветку Clang с поддержкой концептов из C++20, которую развивает Saar Raz, и влили ее в нашу ветку Clangd. Таким образом, мы получили подсветку кода с концептами и базовые проверки анализатора Clang в CLion:
Но на этом мы не остановились. И в нашем движке на базе Clangd мы реализовали некоторые полезные случаи автодополнения, проверку на использование концепта, рефакторинг Rename для концептов, действия навигации и поиска Go to Definition и Find Usages.
Автодополнение для параметров шаблона, на которые наложены ограничения:
Автодополнение для
std::is_same<Other, T> and same_as<T, U>:
Более подробно про нашу совместную работу над концептами можно почитать в англоязычном блоге. Там же есть видео-запись доклада с CppCon 2019, в котором Saar Raz презентовал свою реализацию концептов в Clang и нашу совместную работу по поддержке концептов в CLion.
Метрики покрытия кода
Code coverage — возможность, которую очень ждали и просили пользователи CLion. В прошлом релизе работу в этом направлении начала команда AppCode, а в этом мы подхватили ее для случаев кросс-платформенного C++ уже в CLion.
Работают метрики покрытия кода в CLion через интеграцию с инструментами llvm-cov/gcov. При этом можно запускать как юнит-тесты, так и обычные конфигурации, и по их исполнению будет подсчитываться частота исполнения тех или иных строк кода. Результаты по нескольким запускам можно при желании суммировать в один общий.
Непосредственно результаты можно увидеть либо в специальном окне Coverage:
…либо в левом гаттере в редакторе.
Ну, и самое главное: чтобы это все заработало, требуется передать специальные параметры компиляции:
- Для GCC:
-fprofile-arcs -ftest-coverageили--coverage. - Для Clang: либо такие же флаги, как в случае с GCC, либо
-fprofile-instr-generate -fcoverage-mapping. Отличия будут лишь в способе сборки метрик покрытия.
Почему CLion сам не передает эти параметры? В основном, потому, что у нас есть правило не вмешиваться в процесс компиляции. Да и не всегда понятно, куда передавать эти параметры в случае не CMake. Но сейчас мы думаем над вариантами того, как все же такие случаи в будущем автоматизировать (аналогичная проблема у нас есть и с санитайзерами).
Более подробно про опции компиляции и про отображение метрик в CLion можно почитать в нашем онлайн-хелпе.
Другие улучшения
Среди других важных улучшений в этом релизе:
- Поддержка подсистемы WSL2. Настройки в CLion у нее такие же, как у WSL первой версии.
- Поддержка правил форматирования и именования от Microsoft. Данный стиль доступен наравне с Google, LLVM, Qt, GNU, Stroustrup и другими в Settings/Preferences | Editor | Code Style | C/C++.
- Обновления плагина IntelliJ Rust (этим изменениям посвящен детальный пост в нашем англоязычном блоге).
- Обновления поддержки VCS, пользовательского интерфейса и другие изменения из платформы IntelliJ.
Демо
В заключение, традиционный ролик о новых возможностях CLion 2019.3 (на английском):
Спасибо, что дочитали до конца! Наверняка у вас есть вопросы, пожелания, баг-репорты и просто мысли — ждем их в комментариях! Как всегда, с удовольствием ответим и обсудим ваши идеи.
Ваша команда JetBrains CLion
The Drive to Develop
Комментарии (67)
vamireh
09.12.2019 13:15anastasiak2512 скажите, а почему ключевые слова final и override не подсвечиваются в объявлении метода?
anastasiak2512 Автор
09.12.2019 13:19Как мы выяснили, эта такая особенность подсветки через Clang. Мы это поправили, но в релиз и критикал-апдейт не успели положить. Должно быть в следующем апдейте (2019.3.2). Вот тут тикет.
vamireh
09.12.2019 14:41Понятно, ждём апдейта.
А ждать ли поддержки Doctest? Как я понял, в ReSharper C++ уже есть.anastasiak2512 Автор
09.12.2019 16:10Пока не планировали. В ReSharper C++ действительно есть. В CLion пока нет свободных ресурсов для задачи с таким приоритетом (не очень высоким).
gudvinr
09.12.2019 13:43А фризы, к сожалению, так и остались.
anastasiak2512 Автор
09.12.2019 13:45К сожалению, пофиксили еще не все. А вот от того конкретного, есть тикет с thread dump-ом?
gudvinr
09.12.2019 13:56Да, есть тикет CPP-13493, добавил дамп для последней версии.
anastasiak2512 Автор
09.12.2019 14:00Ага, спасибо. Сейчас глянем, что там такое.
Есть еще, к сожалению, тяжелые фризы, которые не просто извести. Но мы их будем тоже исправлять, правда для этого потребуются большие изменения.
sergegers
09.12.2019 14:42А с Resharper C++ как обстоят дела?
anastasiak2512 Автор
09.12.2019 16:11Готовимся к релизу 2019.3 вместе с остальным ReSharper Ultimate. Что-то конкретное интересует?
sergegers
09.12.2019 16:50А там будет code completion для концептов?
anastasiak2512 Автор
09.12.2019 17:55Прямо такой же как в CLion — пока нет. В ReSharper C++ мы работаем над поддержкой концептов в своем языковом движке. Сейчас в EAP-е можно посмотреть на проверки анализатора кода, find usages, rename и некоторое автодополнение (для имени концепта в основном).
sergegers
09.12.2019 17:56Это плохо
anastasiak2512 Автор
09.12.2019 17:58А какой случай кажется наиболее полезным? Мы в целом только начали работу над поддержкой концептов. Просто в ReSharper C++ надо было еще в языковом движке поддержать сначала, а в CLion удалось сэкономить за счет Clang.
sergegers
09.12.2019 18:22Для сложных выражений в static_assert() есть удобный popup, где можно посмотреть, чему равно или какого типа подвыражение, неплохо бы такую же функциональность для концептов. Сейчас там всё ограничивается красным подчёркиванием и фразой concept isn't satisfied.
Ещё интересно автодополнение как в clangd для членов, методов и подтипов.
Ну и, конечно, всё ещё есть не критичный, но существенный процент ошибок вообще, а в выражениях с концептами этот процент значительно выше.
Производительность Resharper C++ удалось подтянуть, по сравнению с ранними версиями. Сейчас, на мой взгляд, она на удовлетворительном уровне.anastasiak2512 Автор
09.12.2019 18:27Мы в ReSharper C++ при ошибках перегрузок пытаемся очень подробно ошибку расписать, чтобы было понятно, какой концепт и почему не удовлетворен. Можно поиграться на EAP-ах или уже дождаться релиза (уже вот-вот!). В CLion мы берем эти ошибки просто из Clang. Они довольно «говорящие», но бывают не очень.
sergegers
09.12.2019 19:03Перегрузки да, там перечисляются кандидаты, и почему каждый не подошёл. А я имею ввиду вот что:
#include <string> #include <concepts> template <typename T> concept int_addable = std::integral<T> && requires (T const &t) { { t + t } -> T; } ; template <int_addable T> void foo(T &t) {} int main() { foo(std::string{}); }
хотелось бы сообщения:
concept int_addable isn't satisfied for function foo() // это есть because the clause std::integral<T> isn't satisfied for type std::basic_string<char, std::char_traits<char>> // а этого нет
AndDav
09.12.2019 18:58Если вы знаете какие-то примеры ошибок вообще и с концептами в частности, сообщайте нам, пожалуйста, о них. Исправление красного кода для нас (ReSharper C++) приоритет номер один.
sergegers
09.12.2019 19:09Мне, честно говоря, показалось, что такие ошибки вы правите по остаточному принципу. Ок, я буду интенсивнее открывать тикеты.
sergegers
10.12.2019 15:27Да, а вот ещё хотел спросить. Поддержка модулей планируется, и если да, то когда её ориентировочно ждать?
anastasiak2512 Автор
10.12.2019 15:31А что входит в поддержку модулей в вашем понимании? В CLion вообще с Clang подсветка, автодополнение и пр. из коробки будет работать вероятно.
sergegers
10.12.2019 15:42Для немодифицированных файлов доступно готовое AST, что должно повысить скорость парсинга на порядок, определение циклических импортов.
Но даже самая начальная поддержка должна обрабатывать директивы module, import, export.
Misaka10032
09.12.2019 14:48Хм, а можно очень тупой вопрос?
Давно хотел попробовать CLion, но так как основное моё занятие — embedded, то повода как-то не было.
Недавно начал ковырять современные плюсы(сейчас хочется врезать себе за многолетнее сидение на чистом Си) и начал пытаться участвовать в opensource.
Я правильно понимаю, что если проект использует Cmake — я смогу его запускать и отлаживать?anastasiak2512 Автор
09.12.2019 16:12Да, CLion поддерживает CMake как нативную проектную модель. Можно открывать, запускать, отлаживать такие проекты. Также поддержан Gradle для C++ и compilation database, если создать custom build targets & custom run/debug configuration. То есть в целом, через compilation database можно любую проектную модель открыть.
lamerok
09.12.2019 20:45Да можно, единственное, нормально поддерживается только GCC, причём не все версии, остальные немного кривовато поддерживаются или вообще не поддерживаются. Жду поддержку IAR нормальную.
Отладка через GDB работает не плохо, но если отладчик какой то китайский, то будьте готовы много и долго настраивать конфигурацию для него.
Ну т. е. если только CMake хотите для какого-то неизвестного тулчейна, то не все так просто. Работать будет, но не все.
fougasse
09.12.2019 21:06Используем разные gcc с 4 по 9, свои тулчейны, расскажите пожалуйста, что не должно работать?
Misaka10032
10.12.2019 09:03У меня как раз GCC, проект десктопный.
Вчера попробовал — указал путь к проекту, завелось с полпинка.
В общем, пока очень нравится. Проект большой(Kicad), но работает довольно шустро.
И такой вопрос — изучил варианты лицензирования, как понимаю, после 30 дней — только покупать? Так как, вроде, я не core developer и, увы, уже не студент.anastasiak2512 Автор
10.12.2019 11:49Да, после 30 дней бесплатной триальной версии вам понадобится лицензия. Можно платить за год, можно по месяцам (если не часто будете использовать, это выгоднее). После непрерывного года оплаты, у вас появляется пожизненная лицензия на ту версию, с которой вы год начали (+баг фикс апдейты на нее). Есть еще бесплатные лицензии на опер сорс. Полный список всяких скидок и пр. можно здесь глянуть.
myrrc
09.12.2019 15:44Спасибо за релиз!
Хотелось бы ещё по поводу отзывчивости заметить — есть какая-то аудитория (включая меня), которая при использовании IDE старается свести к минимуму использование мыши (всё через горячие клавиши).
Проблема в том, что большая часть возможностей CLion-а по рефакторингу отпадает. Например, при рефакторинге сигнатуры функции невозможно переключиться на кнопку Refactor по табу или другим клавишам (фокус скачет между полями типа и названия переменной), другие примеры тоже есть.
Это таки баг или фича?
P.S. IdeaVim использую, но тут он не помогает.
anastasiak2512 Автор
09.12.2019 16:13Кажется, что баг, причем платорфменный. Попробуйте завести с подробным описанием, а мы посмотрим и поищем дубликат, если что.
Unrul
09.12.2019 21:20Сижу ещё с eap, стало намного лучше. Хотелось бы, чтобы при rename запоминались места поиска, вроде last opened files.
anastasiak2512 Автор
10.12.2019 11:51Не очень пока поняла, поясните подробнее? Вызываете Rename в каком-то месте, есть несколько использований символа, они все переименовываются. Что значит запоминалось место поиска в этом случае?
Unrul
10.12.2019 17:12При вызове диалога Rename есть возможность выбрать Scope: All Places, Project Files, Project Source Files и так далее. Выбор не запоминается, то есть, при следующем вызове Rename приходится опять выбирать нужный Scope. Хочется, чтобы выбор сохранялся между вызовами Rename, так как кодовая база очень большая, и даже при отключении поиска в тексте и комментариях, Rename работает очень долго, если не указать более узкий Scope.
slovak
09.12.2019 22:14Обновился на свою голову, сразу же обнаружил, что работа с вкладками происходит теперь по другому. Раньше, при двух вертикальных вкладках, новый файл из Shift+Shift поиска или Ctrl+Tab селектора открывался в текущей активной вкладке, теперь же есть какая-то история, и если файлы был открыт ранее справа — то он упорно открывается справа. И никак не открыть файл одновременно в двух вкладках. В настройках таб ничего такого нет. Ну вот зачем такие поведенческие вещи менять без возможности вернуть обратно по явной галочке в настройках? Пришлось откатываться, и даже не знаю что теперь делать с дальнейшими обновлениями. Может быть есть ли возможность гибко настраивать такие вещи через конфиг файл?
anastasiak2512 Автор
10.12.2019 12:39+1Я правильно понимаю, что вы сделали Split Vertically и хотите, чтобы файл из Search Everywhere открывался в активной половине, даже если открыт в другой? У меня вот сейчас именно так все и работает. Поэтому уточняю.
slovak
10.12.2019 13:06Да, абсолютно верно.
И еще из Ctrl+Tab селектора.
Пример:
1. В двух вертикальных вкладках открыты два разных файла.
2. Я переключаюсь из одной вкладки на другую и один раз выполняю Ctrl+Tab
3. Результат — в обоих табах открыт один и тот же файл.
После обновления вместо открытия одного и того же файла в двух вкладках я получаю автоматическое переключение фокуса на предыдущую вкладку.anastasiak2512 Автор
10.12.2019 14:04да, спасибо, обсудили с коллегами — действительно есть такая проблема, уже починена, попадет в апдейт.
Antervis
10.12.2019 01:31а ваши приборы не показывали часом увеличение потребления оперативной памяти?
anastasiak2512 Автор
10.12.2019 12:41Существенных изменений не видим, хотя, конечно, чем более точный парсинг, тем больше может памяти занимать.
Если вы видите какую-то конкретную проблему, то включите memory indicator в IDE и последите за ним, если слишком много или кажется, что память слишком быстро заканчивается, то пишите нам в саппорт — будем разбираться.
psinetron
10.12.2019 10:21Сделайте наконец нормальную возможность работы с ардуинами и прочими микроконтроллерами. Честное слово, только с вашим подходом и вашими приложениями это будет лучшим предложением на рынке
anastasiak2512 Автор
10.12.2019 12:41+1Мы в процессе) А что такое «номальная возможность работы» можно поподробнее? Чтобы знать, чего конкретно вам не хватает.
psinetron
10.12.2019 12:47Вау, это очень здорово! Жду с нетерпением!
Под нормальной возможностью подразумевалось что-то подобное существующим проектам (Arduino IDE, Platform IO), когда нужные библиотеки и платы можно подгружать на ходу. Выбирать компиляторы, отправлять на устройства и т.д.
Существующие решения уж очень неприятны. В ArduinoIDE вообще отвратительно с кодом работать, а PlatformIO уж очень сырая, настолько, что ее порой перезапускать приходится, чтоб она восстановилась.anastasiak2512 Автор
10.12.2019 12:52
Artemiyxxx
10.12.2019 12:41Спасибо за релиз. Есть чему порадоваться. Но в то же время после обновления вкрай испортилась кодогенерация. IDE предлагает какие угодно варианты подсказок, только не связанные с проектом. Подскажите пожалуйста как это исправить
anastasiak2512 Автор
10.12.2019 12:42Лучше более конкретно проблему описать и с примером. Так сложно что-то сказать.
Artemiyxxx
12.12.2019 22:34Ну CLion «предугадывает», что я хочу написать. Если раньше в начале списка подсказок были названия контейнеров/ имена объектов из проекта, а недавно использованные имена поднимались вверх этого списка, то сейчас вверху то, что к проекту отношения не имеет.
Например в проекте есть переменная с именем «calc» когда я начинаю печатать, то сначала IDE предлагает calloc(), clock(), еще много чего, что я даже не инклюдил(calc будет где-то в середине списка), и только ближе к концу ввода имя нужной переменной/ класса. Кстати недавно использованные имена теперь в этом списке вверх не поднимаются.
Проблема появилась после обновления.yvvan
13.12.2019 13:17Спасибо за фидбэк, мы попробуем разобраться с проблемой. В основном она вызвана тем, что мы объединяем подсказки из двух движков, которые по разному работают с приоритетами. Пока вы можете отключить clangd completion (Language and Frameworks -> C/C++ -> Clangd -> Use code completions from clangd).
Ссылка на тикет по улучшению приоритетов элементов — youtrack.jetbrains.com/issue/CPP-18448
Crozzy13
10.12.2019 12:42Эх… Пока нет полноценной поддержки Makefiles, придется ковылять на VSCode :(
anastasiak2512 Автор
10.12.2019 12:42Ну, пока что можно в полуавтоматическом режиме через compilation database. Нативная поддержка, надеемся, будет готова к 2020.1
TimCherry
10.12.2019 12:42Браво! Действительно крутые фичи.
Но когда ждать ждать поддержку дебага под MSVC?anastasiak2512 Автор
10.12.2019 12:45Так есть уже экспериментальный отладчик на базе LLDB для MSVC с прошлого релиза! Вот тут описано, как его включить.
nikitablack
10.12.2019 14:22Мы с командой ужасно недовольно быстродействием отладчика. К 10-секундным ожиданиям подгрузки переменной я как-то привык (шучу — не привык, бесит ужасно), но то, что дебаг сессия иногда вообще отваливается из-за доолгого ожидания, это уже перебор. Вы делаете что-нибудь в этом направлении?
anastasiak2512 Автор
10.12.2019 17:05Мы, конечно, анализируем скорость отладчика. Но давайте начнем с того, сабмитили ли вы нам логи на конкретно ваш кейс? Вот так их надо собрать intellij-support.jetbrains.com/hc/en-us/articles/206560589-What-to-do-if-debugger-doesn-t-work-as-expected- Так будет проще понять, что именно у вас за проблема и какой естимейт на починку.
aspera86
10.12.2019 17:05Спрошу здесь:
1) Подскажите как включить подсветку синтаксиса (просто базовую) Groovy (ну или чего похожего). У меня в корне проекта Jenkinsfile и править его хочется прям в Clion. Пробовал указать что это например JavaScript, но он ошибками разукрашивает так что становиться не читабельно.
2) В CentOS 7 ( Mate) если переключить на другое окно (например браузер), а затем нажать мышкой на панели (чтоб переключить обратно в Clion) то не разворачивается, приходиться нажать свернуть браузер.
3) Deployment по SFTP: все настроил, коннектится. В Mappings добавил 2 папки, в них складываются готовые бинарники (bin и lib), установил галочку Automatic Upload. Так вот при перекомпиляции новые бинарники не заливаются автоматом на сервер, приходиться на каждом мышкой: Upload to . Если же удалить бинарник, то он автоматом удаляется и с сервера.
Либо со мной что не так, либо лыжи не едут.
И еще:
Планируется ли «настоящая» удаленная разработка? как бы по системе клиент-сервер, чтобы парсер исходников работал на удаленной машине (и ресурсы на это потреблялись только там), а на клиенте только отображение. Проект большой и если подмонтировать по ssh папку и канал не очень, то это ужасные тормоза. Собирать проект локально — нужно локальную машину хорошую с нужной архитектурой, что не всегда возможно (напр для POWER8+).anastasiak2512 Автор
10.12.2019 17:46То, что вы описываете, похоже на вот этот запрос. Можно повоутить.
А про «настоящую удаленную разработку», когда-нибудь наверное планируем, но не в самое ближайшее время. Сейчас вариант удаленной разработки — это локальный парсинг, а сборка/запуск/отладка — на удаленной машине. Тонкий клиент, который только UI фактически, это возможно теоретически и в эту сторону будем обязательно думать.
monah_tuk
11.12.2019 05:21В этом релизе также появились настройки CMake по умолчанию.
На скриншотах мы видим поле ввода "CMake options:". Сделайте настройки параметров как это реализовали Qt Creator и cmake-gui. Да, при таком подходе получится взять реестр настроек у CMake только после его первого прохода. Но, для грамотно составленных CMakeLists.txt вполне возможно для редактирования полей использовать делегаты, к примеру для типа FILEPATH использовать диалог открытия файла, для PATH — директории; для значений типа BOOL использовать чек-боксы; для трюка с перечислениями — предоставлять выпадающие списки; для остального — поле ввода значения. Причём, есть возможность выводить и подсказку, что это за свойство и для чего оно нужно (это всё выполняется соглашениями в CMake и будет работать как минимум в cmake-gui и QtC):
CMake options screenshot
anastasiak2512 Автор
11.12.2019 11:59Мы, конечно, смотрим, как сделано в других IDE. И попробовали уже несколько разных вариантов с CMake настройками.
Настройки CMake Profiles сделаны сейчас в виде диалога, но их можно менять и в CMakeCache напрямую (раньше был некий UI, потом нас попросили вернуть редактирование кеша как файла). Диалог имеет приоритет над кешом. В принципе, есть план в будущем сделать и какой-то GUI редактор кеша.
Кастомные шаги в Run/Debug конфигурациях сделать можно и сейчас. Там можно любой external tool вызвать на таком шаге. Наверное, можно каких-то предконфигурированных шагов тоже туда забить. Наверное, можно завести реквест в трекере и делиться там своими такими хотелками, мы посмотрим, какие шаги самые популярные и сделаем pre-config для них.
Сейчас там такой список:
Вообще сейчас команда уже довольно давно обсуждает переделки в районе Toolchains / CMake profiles. Скоро должно стать более гибко и удобно.
Fedorkov
11.12.2019 16:02Имхо, очень неудобный folding сделали. Теперь collapse all сворачивает все блоки { } внутри функций, хотя функция — это обычно минимальный scope, который удобно держать перед глазами в развёрнутом виде.
anastasiak2512 Автор
11.12.2019 18:02Унифицировали с платформой поведение. Но изменения под ключом в регистре — можно вернуть, как было, если выставить в Registry: cidr.enable.show.block.folding в false.
phantom-code
Ребята, вы молодцы, новые фичи классные, чувствуется ззначительное повышение производительности во многих местах. Одна просба: пожалуйста, исправьте уже тормоза при наборе текста в редакторе. В хоть сколько-нибудь серьезном по объему проекте достаточно зажать Enter или Backspace и начинается диафильм.
Ссылка на групповой issue по теме: youtrack.jetbrains.com/issue/CPP-988
Спасибо.
anastasiak2512 Автор
Мы постоянно работает над тем, чтобы улучшить отзывчивость редактора. К сожалению, в этом общем тикете собраны очень разные проблемы. Поэтому в идеале, если хотите именно про ваш случай узнать поточнее, в чем проблема и когда будет исправление, заводите новый и прикладывайте CPU snapshot. Если вдруг он окажется дубликатом существующего — не страшно, мы слинкуем их сами. Просто групповой тикет, вероятно, будет самым долгоживущим)
dion
У меня тоже на некоторых файлах тормоза такие что проще в vim редактировать:
https://youtrack.jetbrains.com/issue/CPP-16887