company_banner

Новости CLion: релиз 2020.1, пятилетие IDE и онлайн-сессия вопросов и ответов

    Привет, Хабр!

    Столько всего хочется сегодня рассказать, что даже сложно выбрать, с чего начать. Так что сначала попробую коротко обо всем самом важном:

    1. Продукту CLion вчера исполнилось 5 лет! В честь праздника мы смонтировали небольшую видеоисторию, своеобразное воспоминание и рассказ о том, как же интересно все развивалось для нас эти 5 лет. Сразу предупредим, история на английском:


    2. Вчера же случился первый в этом году большой релиз продукта – CLion 2020.1. В нем мы поддержали диалект CUDA, переписали Dataflow Analysis на Clang, научили IDE работать с компиляторами Clang-cl и IAR, а также внесли множество других улучшений и исправлений.
    3. Последние несколько месяцев нашей команде стало очень грустно без конференций и сопутствующих выставок, где мы всегда с удовольствием находимся у стендов компании и много общаемся с нашими пользователями и сообществом в целом. Поэтому мы решили организовать онлайн-сессию вопросов и ответов с командой – CLion Ask Me Anything (AMA) session. Сессия пройдет 7 мая в режиме реального времени, требуется предварительная запись. Присоединяйтесь и задавайте любые вопросы по продукту!

    Теперь давайте поговорим подробнее обо всех этих событиях.

    CLion-у — пять!


    Взросление детей всегда удивительно и зачастую неожиданно для родителей. С продуктом та же история — вроде только вчера запускали раннюю версию и вели итоговый отсчет к релизу 1.0, а сегодня уже отмечаем круглую дату. CLion сейчас — это более 200 тысяч пользователей ежемесячно, среди которых команды таких компаний, как BMW, NASA, Tencent, Tesla и многих других, и конечно, сотрудничество с Google и Android Studio.

    Мы рады поддерживать множество студентов по миру, которые именно с CLion делают свои первые шаги в разработке программного обеспечения. И безумно счастливы знать, что треть команд ICPC в финале 2019 также использовали CLion!

    ICPC tools Final

    Волнение с каждым новым релизом, ответственность перед огромным количеством наших пользователей, сплоченность команды, которая делает огромное дело, — все это переполняет нас, и мы счастливы разделить наш первый небольшой юбилей со всем сообществом Хабра! Надеемся, ролик вам понравился ;)

    CLion 2020.1


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

    • Поддержка диалекта CUDA.
    • Для разработчиков встроенных систем — поддержка компилятора IAR и плагин для интеграции с PlatformIO.
    • Обновленная интеграция с инструментами Clang — мигрирование DFA на Clangd, улучшенное автодополнение, более тесная работа с Clang-Tidy и ClangFormat.
    • Для разработчиков на Windows — поддержка компилятора Clang-cl и отладчик по умолчанию.
    • Значения параметров по умолчанию в рефакторинге Change Signature.
    • Более удобные конфигурации для запуска и отладки, включая перенаправление ввода и поддержка макросов IDE.
    • Обновления форматтера, улучшения редактора и многое другое.

    CUDA


    CLion теперь поддерживает диалект CUDA C/C++. Поддержка включает в себя:

    • корректный парсер кода (для исключения «красного» кода и некорректной работы анализатора кода);
    • подсветку и разнообразные умные действия, такие как навигация и просмотр документации;
      CUDA quick doc
    • обновленный мастер создания новых проектов — теперь в него включен шаблон для проектов CUDA;

      CUDA new project
    • поддержку расширений файлов CUDA (.cu/.cuh);
    • специальные таргеты CMake для CUDA — диалог добавления нового файла теперь предложит добавить его не только в подходящие таргеты, созданные обычными командами CMake, но и специфичными для CUDA (cuda_add_executable / cuda_add_library);

      CUDA add to targets
    • и даже автодополнение для угловых скобок для вызовов ядра:

      CUDA completion

    Примечание: для тестов и скриншотов использовался настоящий CUDA-проект с GitHub: ClaraGenomicsAnalysis.

    Нас спрашивали, почему же мы так сфокусировались на CUDA, а не других специфических областях, например Qt. Если коротко, то мы бы, конечно, хотели поддержать все типы проектов на C/C++ в нашей IDE. Но в условиях ограниченных ресурсов приходится делать выбор и скорее сосредоточиться на поддержке максимально универсальных возможностей. Такие диалекты, как CUDA, если не поддерживаются «из коробки», то приводят к красному коду, ошибкам анализатора кода и другим проблемам с основными возможностями IDE. В отличие от Qt, где общий парсер вполне справляется с кодом и только не хватает каких-то специфических возможностей.

    Для разработчиков встроенных систем


    Мы продолжаем работу по поддержке разработчиков встроенных систем. Благодаря взаимодействию с компанией IAR Systems AB мы смогли получить партнерские лицензии и добавить в CLion поддержку компилятора IAR. Раньше мы не могли правильно считать информацию от компилятора и такие проекты не загружались в CLion корректно. Теперь все работает!

    IAR compiler

    Стоит отметить, что для использования компилятора требуется использовать тулчейн MinGW. А вот здесь можно найти несколько советов о том, как использовать CMake с IAR Embedded Workbench.

    Мы продолжим сотрудничество с IAR Systems AB, и, надеюсь, в один прекрасный день в CLion также появится поддержка их отладчика.

    С самого первого релиза CLion мы общались с создателями PlatformIO, уникальной экосистемы для быстрого старта проектов под встроенные системы. Например, многим она помогла начать первый проект на Arduino. К релизу 2020.1 мы собрали хоть и довольно базовый, но полезный плагин PlatformIO for CLion. Самая главная его возможность — создать проект для PlatformIO на основе CMake, для этого достаточно выбрать такой тип проекта в мастере создания новых проектов:

    PlatformIO plugin

    Плагин автоматически создает конфигурации запуска и отладки, специфические для PlatformIO, а также позволяет отлаживать с помощью отладчика PIO Unified Debugger прямо из CLion. Больше информации можно найти в официальной документации. Пробуйте и пишите ваши пожелания по дальнейшему развитию — мы сейчас как раз раздумываем, куда и как развивать этот плагин дальше.

    Обновленная интеграция с инструментами Clang


    Как уже известно, мы сейчас активно портируем все больше и больше возможностей на языковой движок на основе Clangd. Во-первых, чтобы быстрее получать поддержку новых возможностей языка и адаптировать действия IDE для них, а, во-вторых, чтобы в некоторых случаях улучшать производительность редактора (не везде, к сожалению, Clangd является таким универсальным средством).

    В релизе 2020.1 мы много времени уделили исправлениям в автодополнении на основе Clangd (оно появилось в версии 2019.3). И, решив, что результаты у такого подхода довольно хорошие, включили по умолчанию режим, в котором опции для автодополнения берутся полностью из Clangd. Включить обратно смешанный режим работы можно в настройках:

    Clangd completion

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

    На Clangd в этом релизе также переехал анализ потока данных (DFA). Этот анализатор заслуживает отдельной статьи, ибо умеет и делает то, чего не делают обычно компиляторы (в основном потому, что им это не нужно, хотя теоретически это возможно и на их стороне воспроизвести) — анализирует, как данные движутся по графу потока управления и, исходя из этого знания, находит потенциальные ошибки. Например, условия, которые всегда истинны или ложны, бесконечные рекурсии и циклы, пропущенные return-выражения, неиспользуемые значения, параметры и локальные переменные:

    DFA always true

    Теперь это все работает на Clangd. И мы надеемся, что это улучшит производительность анализов кода на ваших проектах. К сожалению, раньше нам часто приходилось советовать пользователям отключить именно анализ DFA для улучшения производительности редактора. Если это ваш случай — предлагаем вам включить анализатор обратно. Будем ждать ваших отзывов в нашу техподдержку и трекер.

    В довершение про инструменты Clang стоит отметить улучшения в поддержке Clang-Tidy и ClangFormat:

    • При обнаружении в проекте конфигурационного файла .clang-tidy CLion автоматически отключает настройки Clang-Tidy в IDE и переходит на использование данного конфигурационного файла. Поведение управляется настройкой.
    • При обнаружении в проекте конфигурационного файла .clang-format CLion автоматически переключается на использование ClangFormat как инструмента форматирования кода на данном проекте. Если же вы решили переключиться на ClangFormat, но подходящего конфигурационного файла в вашем проекте нет, то CLion предложит его создать, выгрузив туда текущие настройки форматирования.

    Для разработчиков на Windows


    Если на Linux и macOS тулчейн в CLion выбрать довольно просто (берем либо GCC, либо Clang), то на Windows существует множество опций, в которых нелегко разобраться: Cygwin, MinGW/Mingw-w64, WSL, Visual Studio. При этом в рамках каждого тулчейна зачастую используют разные компиляторы. Нас долго просили о возможности использования Clang на Windows. И в CLion 2020.1 появилась возможность взять Clang-cl (либо с официального сайта LLVM, либо вместе с инструментами Visual Studio) и использовать его в рамках тулчейна Visual Studio:

    Clang-cl

    Кстати, вы заметили отладчик, выбранный по умолчанию в этом диалоге? Тот самый отладчик на базе LLDB для тулчейна Microsoft Visual C++, который разрабатывает наша команда и который мы представили в прошлом году, включен в новой версии по умолчанию! Правда, если вы хотите воспользоваться также поддержкой Native Visualizers, ее все же надо явно включить в настройках: Settings | Build, Execution, Deployment | Debugger Data Views | Enable NatVis renderers for LLDB.

    Рефакторинг Change Signature


    Среди множества рефакторингов в CLion выделяется Change Signature (Ctrl+F6 на Windows и Linux, ⌘F6 на macOS). Он позволяет изменить имя функции, тип возвращаемого значения, список параметров. При этом IDE обновляет все использования функции, чтобы сохранить корректность кода. Но что делать, если вы добавляете новый параметр? Раньше CLion во все использования проставлял значение типа по умолчанию (если оно есть) – 0 для чисел, nullptr для указателей. Теперь же, с версии 2020.1, появилась возможность указать значение, которое CLion подставит в использования функции, прямо в диалоге рефакторинга:

    Change Signature
    Если не указать ничего, то поведение будет как раньше.

    Конфигурации запуска и отладки


    Множество небольших улучшений в конфигурациях запуска и отладки в CLion сделало их гораздо более удобными в использовании.

    Во-первых, конфигурации Remote GDB Server и Embedded GDB Server работают теперь с кастомными таргетами, а не только с таргетами CMake. Так что теперь отлаживаться на удаленной машине или на микроконтроллере можно не только в случае проекта на базе CMake, но и для любого другого типа проекта, для которого вы настроили кастомные таргеты (указав команды сборки и очистки проекта).

    Во-вторых, для конфигураций типа CMake, Custom Build и Gradle Native Applications появилась возможность использовать макросы и переменные путей. С их помощью можно получить доступ ко многим полезным значениям:

    IDE macros

    И, наконец, в этих же типах конфигурации появилась опция перенаправления ввода программы. В сочетании с макросами Prompt/FilePrompt, она позволяет не только перенаправить ввод в программу из файла, но и показать диалог для выбора файла для ввода на старте конфигурации:

    Input redirection

    Обновления форматтера, улучшения редактора и многое другое


    Стоит упомянуть еще несколько небольших точечных улучшений в разных подсистемах:

    • Отдельные настройки именования для полей структур и полей классов.
    • Возможность сворачивать блоки кода, выделенные при помощи #pragma region / #pragma endregion.
    • Окно просмотра документации теперь можно не только вызывать по шорткату, но и увидеть просто при наведении мышкой на интересующий символ.
    • Шрифтом по умолчанию в IDE теперь является JetBrains Mono — новый моноширинный шрифт от JetBrains, созданный специально для разработчиков и помогающий оптимизировать читаемость кода.
    • Светлая тема по умолчанию теперь одинаковая на всех трех платформах – IntelliJ Light.
    • Сессии терминала можно разбивать на несколько по горизонтали или вертикали. Таким образом, несколько сессий видно одновременно в одном табе.
    • Из платформы IntelliJ приехали также улучшения в интеграции с системами контроля версий.

    CLion Ask Me Anything


    Онлайн-сессия вопросов и ответов (на английском) с разработчиками из команды CLion запланирована на 7 мая. В сессии примут участие члены команды, отвечающие за следующие подсистемы:

    • Языковая поддержка C и C++, движок на базе Clangd, адаптация новых стандартов языка C++ в CLion.
    • Проектные модели.
    • Отладчики.
    • Форматирование кода (как родным инструментом, так и с помощью ClangFormat).
    • Модульное тестирование и интеграция с различными фреймворками.
    • Разработка встроенных систем.
    • Удаленная разработка.

    Сессия бесплатная, но требуется предварительная регистрация. Мы также просим вас заранее подумать и по возможности уже в форме регистрации оставить вопросы для команды. Будет возможность задавать вопросы и по ходу сессии, через специальную форму (а я буду это все модерировать и раскидывать вопросы по коллегам), но у вопросов, заданных заранее, больше шансов получить развернутые ответы в начале сессии.

    На этом на сегодня все. Дочитали до конца? Спасибо вам огромное за внимание! Пишите вопросы, предложения, восклицания в комментариях — мы всегда с радостью их читаем и отвечаем!

    Команда CLion
    The Drive to Develop
    JetBrains
    Делаем эффективные инструменты для разработчиков

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

      +4

      Есть в планах выпуск Community Edition, хотя бы с урезанным функционалом, но с поддержкой дебаггера?

        0
        Пока нет. Не очень понятно, что и как урезать.
          0
          Например, выкинуть поддержку юнит-тестов, фреймворков (типа Qt), embedded- и удаленную разработку, поддержку экзотических систем сборки, ядра CUDA, шейдеры OpenGL/OpenCL/HLSL (если вы будете некоторые фичи из ReSharper C++ втаскивать в CLion), всякие штуки для enterprise-разработки типа консоли БД, динамические анализаторы, в т.ч. code coverage и valgrind.

          Т.е. оставить базовый функционал, приблизительно как это было сделано в IntelliJ IDEA Community Edition: умный редактор кода, поиск/навигация, анализ кода на лету, локальный запуск и дебаг, поддержка GNU Make и CMake, документация Doxygen, SVN/git/..., поддержка плагинов.
            +3
            Из парсера довольно сложны вырезать поддержку всяких штук типа CUDA. И вообще языковой движок – это практически основная наша работа. Да и то, что вы перечисляете для community, выглядит как довольно большой пласт функционала. Так или иначе, мы думали о такой возможности, но пока что решили, что не планируем выделять Community версию.
        0
        Планируется ли поддержка Meson?
          0
          В ближайшее время, наверное, вряд ли. Но тикет вот тут
          +2
          CLion — первый продукт от JetBrains, который меня разочаровал. Настолько медленно работает с Qt, что пришлось вернуться к VS.
          Да, я прочитал все ваши советы по ускорению работы: добавил памяти, отключил лишнюю инспекцию. Но автокомплит, как и подсветка имеют просто чудовищный отклик: напечатать какую-нибудь переменную с типом получается быстрее, чем получить ее.
          А вот так сейчас проходит установка вашей новой версии:
          image

          Процесс не заканчивающийся уже добрых 25 минут. Взяли пример у Microsoft и решили тестировать продукт на кошках пользователях? Пришлось убивать руками.
          И зачем вы в новой установке включили по умолчанию свой шрифт, а не выбранный пользователем? Он с ним работал, если бы этот шрифт мешал, он выбрал бы другой, это очевидно. Поломали плагины. Процесс обновления плагинов просто висит, приложение зафризилось. Но какая, однако, бодрая статья. Пока висит ваше приложение, пожалуй, еще раз перечитаю, мне же больше делать нечего теперь. (завершаю через диспетчер второй раз за утро).
          Давайте, все же попробуем открыть проект, чтобы показать, что я имею ввиду под словом
          ЧУДОВИЩНО:


          на 21 секунде я вызываю автокомлит. Он не вызовется даже после того, как это минутное видео зальется на сервер. Наверное, это очень сложная и очень редко используемая функция IDE, поэтому на нее не стоит обращать внимание. Хотя ваши коллеги из PhpStorm почему-то с ней справились и даже на сложных фреймворках все выпадает во вполне себе бодром режиме.
          Ваш продукт — сырой. Вот, что я могу вынести в качестве заключения. Мой проект крошечный по сути, использует один из самых известных C++ фрейморков в мире. И я не могу с ним работать в вашей среде.
          И нет, не железо виновато. На всех трех используемых мной в работе машинах стоят ssd и не менее 8 GB RAM, core i5. И на самой быстрой из них автокомплит someFunction() начиная с первых двух символов названия класса получится примерно за 5-7 секунд.
          Смешно, но средой разработки приобретенной за деньги у JetBrains я пишу совсем простенькие обучающие с++ вещи из нескольких классов (и в них автокомплит работает на ура) и редактирую CMakeList, а коммерческое приложение, которое дает мне хлеб (и позволяет продлять подписку на JetBrains) приходится разрабатывать на плохом с т.зр. реализации функциональности как среды, но вполне переваривающим мой проект Visual Studio.
          Хочется спросить компанию JetBrains: извините, а вы можете просто сделать приложение работающим, без бодрых рапортов, но хорошо отлаженным и протестированным?
          P.S. я не мазохист, если что. Расширил подписку, которая у меня была только на одну IDE из-за ударной работы ваших коллег из команды DataGrip, и поскольку перешел на плюсы. Не думал, что вы меня так подведете с одним из флагманских продуктов.
            +1
            Мне искренне жаль, что у вас такой опыт с CLion. Так, конечно, не должно быть. Давайте посмотрим по порядку

            1. Проблемы с медленным апдейтом, кажется, я уже видела. Это что-то именно в Toolbox вроде. Сейчас уточню у их саппорта, видели ли они такое на 2020.1 билдах. Без него патч накатывается вроде довольно бодро.

            2. Про плагины — а без Toolbox они тоже долго висят и не обновляются? Можно тогда хотя бы idea.log попросить?

            3. Про шрифт. Мы меняли дефолты. Вот тут объясняли, как это устроено и почему меняли. Если пользователь выбрал какой-то кастомный шрифт, переключения не должно было произойти, но кажется, какие-то проблемы все же с этим есть. Приносим свои извенения, если это и ваш случай.

            4. Ну и наконец про автодополнение. Вообще судя по видео, там вообще код не порезолвился. Покраска дефолтовая. Надо бы посмотреть, что там произошло. Можете как-то пингануть в саппорте или в трекере нас? Нам скорее всего нужны какие-то логи, как минимум, чтобы поизучать.
              –1
              «Код не прорезолвился», это, кстати, еще одна из проблем. Я понимаю когда он индексируется первый раз. И не понимаю, когда я загрузку системы получаю практически через каждое открытие проекта. Вот, полюбуйтесь,
              переоткрыл ТОЛЬКО ЧТО закрытый проект
              image
              — это нормально по вашему?
              А вот примеры автозаполнения с предыдущего «прорезолвенного» состояния (подсвечены методы и члены класса):
              с методом класса-родителя
              image

              и никаким вовсе, хотя вот же он:
              image

              Относительно вашего предложения «пингануть» в саппорте. В данный момент я испытываю самые гнусные подозрения, что компания JetBrains подвержена согласно моей теории той же самой энтропии, что подвержены любые крупные IT компании, ломающие свои собственные продукты. И поэтому никакого особого смысла в сотрудничестве с такой компанией не будет. Обращу ваше внимание, что даже ваше предложение является делегирующим. Не "спасибо за описание, я создал(-а) тикет вот тут, вы можете его дополнить?", а "пинганите нас". Разница очевидна?
              Уверен, что проблема не в том, пингану я вас или не пингану (спойлер: пингану), а проблема как раз в подходе к разработке, когда на транспаранте смеющиеся лица, а под капотом страх, боль и разочарование от компании, продукты которой постоянно советуешь использовать (спойлер: вчера был последний раз, после того как увидел вот эту «оду», понял, что ваша звезда закатывается и выбор продукта для разработки опять будет ситуативным, без бренда).
                +3
                Я предложила написать в саппорт, потому что ситуация не нормальная, явно что-то идет не так в вашем случае, вероятно баги на нашей стороне. И мы бы очень хотели как минимум разобраться, а в идеале и постараться побыстрее поправить. Но по скриншотам, к сожалению, мы еще не научились догадываться до сути проблем. Довольно много зависит от окружения, тулчейна, настроек. Бывает еще, что падает clangd-движок и тоже к таким проблемам с парсингом приводит, но опять же это видно по логам, но не по видео. Мы обязательно заведем проблемы в трекере (и конечно с радостью сделаем это сами), как только разберемся соб-но, в чем проблема. Поэтому если не сложно, напишите на clion-support@jetbrains.com. Наши саппорт инженеры очень отзывчивы и всегда на связи с командой. Так что постараются посмотреть на запрос в ближайшее время.

                (и да, повторной индексации на уже проиндексированном проекте происходить в штатной ситуации не должно, но что-то я подозреваю, что что-то там идет совсем не по плану)
                  +2

                  Зря кстати. Тех поддержка вполне себе ОК.


                  C Qt-ными проектами сейчас грустновато немного. У меня CLion банально не может найти autogenerated файлы (типа uic_XXX.h). CPP-17487


                  На сравнительно небольших проектах/халтурках всё таки летает.


                  Но с чем-то тяжелым IDE таки начинает резко тормозить. По моим ощущениями тормоза пропорциональны количеству GTest-based кода. В моём случае это частично решилось хоткеем на 'killall clangd'… И частичным переключением в vim :)

                    +1
                    Про Qt хедеры — а они находятся, если собрать проект и потом перезагрузить CMake?

                    Про тормоза, я понимаю недовольства. Мы действительно знаем про многие перфоманс проблемы. И над ними много работаем. Что-то исправляется как раз таки переходом на Clang, где-то требуеются большие архитектурные изменения или вообще принципиально новые подходы, но это тоже в процессе. Мы много пробуем, не все ест-но выходит в релиз. Вот за последние полгода мы несколько раз пробовали LightPSI, такая модель кода, которая будет не совсем корректной, но очень быстрой. Хотели ее построить и подпихивать платформе для тяжелых операций. Пока не вышло. Но у нас еще есть идеи в запасе) stay tuned!
                      0

                      Спасибо. Да. Получается что если сначала собрать всё (чтобы эти ui_ файлы появились), и потом перезагруить CMake проект (Tools -> CMake -> Reload CMake project), то таки со второго раза начинает находить. Но при этом если в такой файл перейти, то сверху в плашечке отображает "This file doesn't belong to any project target, code insight features might not work properly".


                      А вот с Clang интересно. У меня такое ощущение что из-за Clang тормозов только добавляется. Такое ощущение что IDE много где синхронно ждет чего-то от clangd и из-за этого зависает. C тем же включеным ClangFormat много где даже текст нормально вводить нельзя. Вот, например, в CPP-16887 я специально видео записал...


                      Сейчас у меня вообще выключен "Use navigation via clangd".

                        0
                        Это сообщение означает, что с точки зрения CMake как проекта, хедеры не входят в проект. CLion считает, что файл в проекти 1) если CMake про это сообщает или 2) если файл включен черезе include в файле, который в проекте.
                          0

                          Так а смысл этот файл генерировать если он не в проекте? Он как минимум через #include используется. Это воспроизводится на том же примере с CPP-17487.


                          GIF-ка

                          image

                            0
                            Это очень странно. Давайте мы глянем внимательно и ответим вам уже в тикете.
                          0
                          Clang как раз наоборот отвязан от EDT (UI потока), потому что это вообще отдельный процесс. И там по идее никаких таких ожиданий не должно быть. Другое дело, что Clang бывает крешится, мы такое изводим, но новые креши регулярно случаются с обновлением LLVM репозитория.

                          Фриз CPP-16887 кажется не с Clang связан. Смотрим.

                          В целом, мы не рекомендуем отключать наш движок на основе Clangd. Даже не смотря на креши, он, там где используется, показывает результаты не хуже, а зачастую лучше старого движка. А тормоза случаются, как правило, на стыках. И их надо, безусловно, нам править.
                        0
                        По поводу GTest. Если есть подозрение, что тормоза идут от тестовой подсистемы (вроде там все эффективно индексируется в фоне, но мир неидеален, могут быть баги, которые мы пропустили) — его можно подтвердить или опровергнуть отключением плагина поддержки GTests/BoostTest/Catch. Отдельно каждого или всех скопом. Расскажите потом, помогло ли! Может станет понятно, куда копать дальше
                    0
                    А вот так сейчас проходит установка вашей новой версии:
                    Процесс не заканчивающийся уже добрых 25 минут.

                    Он может и больше часа провисеть. Ставить лучше отдельным инсталлятором, а не через Toolbox.
                    Toolbox это bloatware в чистом виде.

                      0
                      Команде Toolbox очень бы хотелось логи получить, когда такое случается. На Windows они живут в \Users\\AppData\Local\JetBrains\Toolbox\logs. Отправить их можно на toolbox-support@jetbrains.com
                    0
                    Во многом отличная IDE, но не хватает мелочей, что приходится сидеть в двух IDE под window:
                    1. запуск в отдельном окне, а не вывод в окно clion. не все можно вывести в консоль.
                    2. при сборке и тестировании библиотек/плагинов нет возможности запустить стороннее приложение. да и перенаправить при сборке место куда положить бинарник нельзя. Да, тут можно накрутить cmake скрипт, но на постоянку не удобно
                      0
                      Спасибо. Попробую ответить по пунктам:
                      1. Первое — это видимо вот этот реквест. На Windows есть с этим проблемы. Еще коллеги подсказали вот такую опцию для MinGW случая.
                      2. Запуск стороннего приложения в рамках конфигурации? Можно указать любой executable в run configuration. И это как раз частый случай для библиотек и пр. А чтобы перенаправить бинарник можно использовать CMake параметр -DCMAKE_RUNTIME_OUTPUT_DIRECTORY=...
                        0
                        1. да, речь про этот реквест. очень ждемс
                        2. нашел, да, можно запустить. Но приложение так же консольное -)) и смотр пункт 1.
                          0
                          А тулчейн какой используется? Там просто есть большие проблемы с тем, чтобы это сделать. Не уверена, что быстро можем.
                    0
                    обновился, все хорошо, кажется даже лучше стало резолвить линки
                      0
                      В 2020.1 было несколько исправлений, связанных с symlinks, если вы про них.
                      +1
                      Странный график IDE на ICPC. Очень удивлен что нет QtCreator'а в списке IDE. Местатми он даже лучше чем CLion
                        +1

                        Интересно было бы узнать, будут ли подвижки в удалённой разработке? Тот функционал который есть очень куцый и с глюками (по крайней мере если CLion на Windows а разработка на Linux), есть открытые тикеты по этим глюкам но что-то воз и ныне там — и уже больше года.

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

                            Самая большая проблема — это невозможность работать с удалённым (remote) кодом напрямую, без локального маппинга, несмотря на то что есть функция "Edit remote file".


                            К сожалению, я не могу вспомнить тикет на эту тему, давно уже это было, но проблема всё ещё есть.


                            Локальный же маппинг (включая "in place") обладает как минимум одним существенным недостатком — нарушаются имеющиеся ACL (как обычные, так и POSIX), вплоть до того что каждое редактирование скрипта (т.е. выполняемого файла) сбрасывает "x" бит. Впрочем, справедливости ради, это проблема всех IDE (Idea/Rider/etc), не только CLion.


                            На самом деле, полноценная функция типа "Open remote project" с прозрачной работой с чем-то вдали по ssh/sftp (с сохранением всех атрибутов и ACL, кешированием всего что дорого каждый раз таскать etc) была бы просто супер, но что-то дело так и не пошло дальше обсуждений.

                              0
                              Локальный же маппинг (включая "in place") обладает как минимум одним существенным недостатком — нарушаются имеющиеся ACL (как обычные, так и POSIX), вплоть до того что каждое редактирование скрипта (т.е. выполняемого файла) сбрасывает "x" бит. Впрочем, справедливости ради, это проблема всех IDE (Idea/Rider/etc), не только CLion.

                              "Settings/Preferences | Appearance & Behavior | System Settings | Synchronization | Use "safe write" (save changes to a temporary file first" — попробуйте отключить эту опцию если она включена.

                                0

                                Тикет — CPP-15986. Штука действительно классная и будет очень востребована, но это довольно сложная задачка. И пока мы только обсудумываем варианты, как к ней вообще подступиться. Конкретный планов или естимейтов пока нет.


                                У нас есть галочка preserve permissions, но она имеет смысл только на Unix. Починить слетающие permissions на той же Windows пока не понятно как.

                            0
                            Улучшенное автодополнение — это, мягко говоря, громко сказано. Оно действительно какое-то время назад изменилось, но не вполне в лучшую сторону. Теперь оно очень любит подсказывать всякие длинные и безумные штуки, часто начинающиеся с нескольких подчеркиваний. Особенно это видно, когда хочется вызвать метод find у std::string: тогда автодополнение любезно предложит простыню довольно специфичных методов find_first_not_of.
                            А беду с областями видимости переменных так и не починили. Например, на просьбу в следующем коде переименовать счетчик последнего цикла с 'i' на 'j' Clion уже пять лет исправно отвечает: «Local variable 'j' already exists in the scope».

                            for (int i = 0; i < n; i++)
                            	for (int j = 0; j < n; j++);
                            
                            for (int i = 0; i < n; i++)
                            	for (int i = 0; i < n; i++);
                            

                              0
                              У меня вот на 2020.1 для s.find первыми идут find варианты. Может, от тулчейна как-то зависит. Спрошу коллег, которые делают clang-based автодополнение. А вы не уточните какая платформа и какой тулчейн используется?

                              Про области видимости — да, это, конечно, косяк. Попробую узнать, почему он затерялось с поля видимости. Спасибо за пинг.
                                0
                                Debian, все дефолтное. Я только что перепроверил, и действительно, первый вариант find, а потом find_first_not_of. Похоже, мой косяк, и это относилось к предпоследней версии, а сейчас уже все хорошо (и даже vector автодополняется без лишних круглых скобочек). Если так, то прошу прощения. Еще одна гипотеза состоит в том, что это может не проявляться на небольших файлах, где все автодополнение работает быстро (а там, насколько я помню, работает два разных автодополнения, одно побыстрее и одно получше), но ее я сейчас проверить не могу.
                                  0
                                  Ну, в 2020.1 действительно поменялось поведение автодополнения. Раньше мы объединяли результаты от старого языкового движка и от Clang-а. И там были проблемы с приоритетами. В 2020.1 мы довели автодополнение на Clang до ума, пофиксили кучу проблем, и по умолчанию включили режим, где работает только один провайдер — Clang.
                              +1

                              Спасибо за релиз!


                              Есть хотя б примерные планы-сроки по поддержке C++20?

                                0
                                Так там большая часть уже скоро сама подъедет, вместе с Clang-ом, во всех базовых вещах вроде автодополнения, подсветки, локальной навигации, анализы. Так что нам остается только писать что-то более умное, в рефакторингах, специфических анализах, и прочем. Соб-но, concepts уже есть с прошлого релиза, например. А что именно интересует? Расскажите, какие возможности бы хотелось иметь в первую очередь?
                                  0

                                  Когда я пробовал (правда, это было дня четыре назад, так что ещё с CLion 2019.3), там и concept красненьким подчёркивалось, и к определению концепта соответствующая команда не переводила. Попробую ещё с 2020.1.


                                  А что до возможностей, которых нет в компиляторах — анализ, удовлетворяет ли тело функции указанным в её сигнатуре концептам, или какие-то концепты забыты. Это было в пропозале на оригинальные концепты 15 лет назад, но из concepts lite это выпилили.


                                  Но это очень большая и серьёзная задача, и я вполне пойму, если даже народ из вашего ресёрч-отдела не захочет в этом ковыряться :)

                                    0

                                    А Вы когда концепты пробовали, случаем не имели Clangd выключенным? Проверьте, пожалуйста, в настройках. Если будет красный код при включенном Clangd, заведите пожалуйста багу в трекере.


                                    Про анализы идея здравая. Мы в целом, о чем-то таком думали, но пока переключились на другие задачи. Мы обсудим, вдруг кто-то из ребят захочет сделать такую "киллер-фичу" )

                                0
                                Хорошие новости, что вы продолжаете радовать нас новыми релизами! Жду с нетерпением хотя бы базовой поддержки Qt/QML. Но… мне тоже пришлось откатиться на 2019-ю версию :( Что-то с производительностью явно пошло не туда. Элементарная прокрутка в редакторе — слайдшоу, даже после того, как все проиндексировалось и ноут наконец-то затих. Не знаю как (и нужно ли?) оформить на это баг, потому что «формально» все окей, а по факту… вот.
                                  0
                                  Для QML есть плагин, не пробовали?

                                  Производительность, если не сложно, порепортите пожалуйста. Если фриз — то thread dump, если просто медленно — CPU snapshot. Мы поизучаем. Заранее спасибо.
                                  0
                                  Спасибо. Обновился. Такое чувство что сменили шрифты. Привыкну))
                                  После обновления ругнулся что плагин «CLion CUDA Run Patcher» что не совместим — ну и ладно, все равно не заметил от него пользы.
                                  «Красный» в CUDA файлах действительно пропал — это радует))

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

                                  А вот по мелочи:

                                  Настроено deployment по ssh на удаленный сервер, настроен mapping папки локальной bin (тут складываются готовые бинарники после компиляции) в папку bin на удаленном сервере. Вроде хорошо все: если в дереве проекта открыть папку bin, выбрать нужный бинарник, правой кнопкой и Upload to serv — то файл улетает на сервер, о чем появляется запись в логах. Но есть в настройках настройка Automatic Upload (always). Как мне казалось, что после локального обновления бинарников (из за перекомпиляции) в папке bin, будет автоматом загрузка их на сервер, но это функциональность не работает, приходится каждый раз мышкой тыкать Upload to serv на каждом файле. Может я не так понял назначение этой фичи? (система везде CentoOS 7)

                                  Ест ОЗУ конечно CLion не мало, на больших проектах, на 2 ГБ выделенных ему отказался работать, пришлось поднять квоту до 4. Ну наверное за удобство надо платить ресурсами))
                                    0

                                    Шрифт по идее должен был поменяться только дефолтный (на наш новый JetBrains Mono), но были замечены ситуации, когда кастомный пользовательский шрифт тоже изменялся. Приносим извинения, если это так.


                                    CUDA диалект теперь и правда поддерживается нативно. Красного кода быть не должно больше.


                                    Но о чем мечтал так и нет: полной клиент серверной работы — исходники парсит на сервере, клиент отображает удаленно.

                                    Да, сейчас и правда другой режим. С исходным кодом работа на машине клиента, а запуск и отладка происходят на удаленной машине. Но то, о чем вы говорите, такое мы тоже активно сейчас обсуждаем и пробуем как-то подступиться к задаче. Не только в CLion, в рамках всех наших IDE в целом. Изучаем подходы.


                                    Про deployment по ssh, отвечу чуть-чуть позже. Уточню детали у коллег.

                                      0
                                      Шрифт по идее должен был поменяться только дефолтный (на наш новый JetBrains Mono)

                                      Да, стоял дефолтный, он и поменялся.

                                      Но то, о чем вы говорите, такое мы тоже активно сейчас обсуждаем и пробуем как-то подступиться к задаче. Не только в CLion, в рамках всех наших IDE в целом. Изучаем подходы.

                                      Думаю это будет прорывная вещь, я такого нигде не видел в IDE (только в некоторых специфических HPC программах), можно было бы вести комфортную разработку с моего любимого старенького макбука например, при этом отлаживая код на разных архитектурах и ОС. А так пришлось завести отдельно машину под CentOS x86_64, а для архитектуры POWER8+ вообще в полу ручном режиме приходится.
                                        0

                                        Про шрифт тогда так и задумывалось. Надеемся, что он вам понравится. Если же нет, всегда можно поменять в настройках.

                                      0

                                      Про deployment по ssh. Можете, пожалуйста, проверить, что у вас не включена галочка в Build, Execution, Deployment | Deployment | Options | Skip external Changes?

                                        +2
                                        Вау! Спасибо огромное!!! все работает! Счастья теперь на весь день)
                                      0
                                      А кто занимается разработкой плагина для Rust? Есть информация когда будет поддерживаться дебагер от Microsoft компилятора? Иногда попадаются зависимости которые не собираются из коробки под другой компилятор в windows. Таким образом приходится выбирать, либо искать другую зависимость либо прощай дебаг.
                                      Для сведения Visual Studio Code работает с Microsoft компилятором для Rust.
                                        0

                                        Ребята, которые отвечают за Rust плагин, говорят, что они про такой запрос знают. И даже пытались завести наш LLDB для MS тулчейна, который для C++ у нас на Windows, для Rust чтобы заработал. Вот по образу и подобию как раз этого расширения — https://github.com/vadimcn/vscode-lldb. Но пока не получилось.

                                        0
                                        Спасибо за развитие проекта! В целом всё работает, хоть и со своими особенностями. Планируется ли поддержка GDB более старых версий, например 7.0.1? (использую на удаленной машине)
                                          0

                                          Честно сказать, сильно сомневаюсь. И GDB, и LLDB проекты доовльно активные, развиваются, улучшаются. И поддерживать старые версии становится очень накладно, да и зачастую там случаются проблемы, которые в рамках старых версий никак не обойти. Поэтому мы стараемся держать широкий, но все же не слишком, дапазон поддерживаемых версий. Поэтому сейчас для GDB диапазон 7.8.x-8.3.x

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

                                        Самое читаемое