company_banner

Релиз CLion 2016.3: улучшения поддержки C11, C++11 и C++14, изменения в работе с проектной моделью CMake и многое другое

    Привет, Хабр! Год потихоньку подходит к концу, кто-то уже готовится к праздничным мероприятиям, а кто-то еще старается завершить все задуманное. А мы вот выпустили третий за этот год релиз нашей кросс-платформенной IDE для разработки на C и C++. Оглядываясь назад (и подводя итоги, как принято делать накануне нового года), нам кажется, что за 2016 год CLion существенно вырос и стал гораздо более зрелым:

    • Как в плане языковой поддержки (variadic templates, auto-import и просто многочисленные исправления в части анализа кода),
    • Так и в плане разнообразных возможностей, повышающих продуктивность разработки (новые опции кодогенерации, complete statement, рефакторинги в CMake),
    • Новых языков (Python, Swift),
    • Ну и, конечно, инструментов, сопутствующих разработке на C и C++ (удаленная отладка и отладка процессов, запущенных не из IDE на локальной машине, поддержка формата документации кода Doxygen, множество улучшений в работе с системами контроля версий).

    Мы старались прислушиваться к нашим пользователям (насколько это было возможно) и ориентироваться на их запросы. Версия 2016.3 не стала исключением и принесла множество долгожданных улучшений:

    • Помимо недостающих возможностей C++11, мы смогли, наконец, начать поддержку возможностей стандартов C++14 и C11.
    • Переработанный подход к работе с проектной моделью CMake решил много сложностей, с которыми сталкивались наши пользователи (от невозможности изменить директорию, в которой запускается генерация CMake, до проблем с производительностью и потреблением памяти).
    • Удаленная отладка возможна теперь и на платформе Windows.
    • В редакторе появилась семантическая подсветка.
    • Повышена производительность при повторной индексации проектов на базе Unreal Engine, а еще мы изучили текущее состояние стороннего плагина для генерации CMake для проектов на UE4 и написали об этом целый отдельный пост.
    • Множество других улучшений и изменений.

    image

    А теперь обо всем по порядку.



    Поддержка C++: C++11 и C++14


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

    Во-первых, это поддержка пользовательских литералов. Мы долгое время не брались за эту задачу, но возрастающая популярность концепции встроенного типа и появление ее использований в std::chrono и других частях стандартной библиотеки привели нас к необходимости ее поддержки. Стоит отметить, что помимо уменьшения количества false-positive ошибок анализатора кода (которые были вызваны отсутствием поддержки пользовательских литералов) и всплывающего окна Quick Documentation (Ctrl+Q на Lin/Win, F1 на macOS), которое теперь корректно отражает тип, CLion также позволяет переименовывать литералы, обновляя определение и все его использования:

    image

    Раз уж речь зашла об операторах, стоит отметить, что CLion умеет теперь искать случаи использования перегруженных операторов (кроме new и delete), что может быть особенно полезно при знакомстве с новым и неизвестным кодом, активно использующим эту возможность языка:

    image

    Еще одна причина множественных ошибок встроенного анализатора кода, которая была устранена в этом релизе, — исправления в поддержке overload resolution. Теперь CLion может правильно выбрать подходящего кандидата, а значит правильно показать неиспользуемый код, найти все использования, переименовать функцию или изменить ее сигнатуру, и т.д. А вместе с этим, среда разработки теперь укажет вам на ambiguous call или отсутствие подходящей функции для вызова — соответствующие инспекции добавлены в CLion 2016.3:

    image

    В целом наша команда расширилась, и в частности у нас появилось больше людей, занимающихся анализом кода. Благодаря этому релиз 2016.3 принес множество изменений в этой области. Например, анализ, полагающийся на вычисления sizeof(), стал платформо-зависимым. Мы также поправили ошибочное предупреждение о неиспользуемой переменной в случае нетривиального деструктора (что особенно важно для так называемой ‘guard’ idiom):

    image

    Кроме того, CLion теперь понимает и корректно учитывает __attribute__(unused) и __builtin_unreachable при анализе кода. И это лишь несколько примеров из множества улучшений статического анализа кода, попавших в CLion 2016.3.

    Важным шагом в дальнейшем развитии языковой поддержки можно считать появление поддержки разделителя разрядов (C++14). Мы надеемся, что в дальнейшем мы сможем уделить время и другим возможностях новейших стандартов языка C++. Если вы захотите обратить наше внимание на что-то конкретное, рекомендуем голосовать за соответствующие задачи в нашем трекере.

    Поддержка C: С11


    Наши пользователи вполне резонно замечали, что поддержка чистого C в CLion немного хромает. Мы наконец решили это исправить и добавили поддержку gcc atomic builtins и ключевого слова _Generic, а для ключевых слов _Thread_local, _Alignas, _Noreturn, _Static_assert, and _Atomic, которые появились еще в обновлениях к версии 2016.2, в этой версии появилась возможность автодополнения для ускорения процесса написания кода:

    image

    Кто-то может здесь вспомнить, что в этой версии планировалось добавить шаблоны проектов, в частности для C проекта. Вынуждены честно признать, что работа ведется, но пока не закончена. Но уже в одном из ближайших обновлений 2016.3.x шаблоны появятся.

    CMake: новый подход


    Этим изменениям предшествовало множество споров и обсуждений. Наш изначальный подход, к сожалению, не устроил многих. Объективная критика активно копилась в трекере. Так, например, запрос про изменение директории, в которой происходит генерация CMake, собрал ~90 голосов и ~90 комментариев. В блоге, в твиттере, вживую на разнообразных конференциях и выставках мы не раз обсуждали проблемы с производительностью, вызванные тем, что CLion собирал все четыре конфигурации CMake для каждого проекта (Debug, Release, RelWithDebInfo, MinSizeRel). И вот, наконец, в версии 2016.3 мы существенно переработали подход и предложили решение накопившихся проблем.

    Теперь CLion собирает только выбранную конфигурацию. Данная настройка, как и путь к директории, где требуется производить генерацию, находится в диалоге проектных настроек Build, Execution, Deployment | CMake. По умолчанию проект собирается в директории внутри исходных кодов проекта с именем cmake-build-debug. В будущем мы планируем дать возможность пользователям изменять и значения по умолчанию (например, чтобы указать директорию для сборки, общую для всех ваших проектов).

    Благодаря этим изменениям стало также возможным открывать проект из директории, где уже произведена генерация CMake, без повторного вызова CMake, что существенно экономит время на открытие проекта. Для открытия проекта достаточно указать директорию сборки или файл CMakeCache.txt:

    image

    Обращаем внимание, что это пока работает только в случае, когда в качестве генератора использовались Makefiles. В противном случае CLion вызовет перегенерацию CMake.

    CMake, как известно, система не самая простая, особенно для новичков. Для упрощения отладки скриптов CMake мы добавили возможность видеть логи вызова CMake команды в окне CMake. А вот редактор CMake Cache был убран. Вместо него среда разработки открывает CMakeCache.txt файл прямо в редакторе, что дает возможность легко добавлять новые значения. В следующих релизах мы планируем обучить CLion “языку” CMake Cache файлов, чтобы сделать работу с ними быстрее и удобнее.

    Удаленная отладка


    В прошлом релизе мы добавили возможность отлаживать из CLion приложения, запущенные на удаленной машине из-под GDB-сервера. Правда, не все комбинации локальной и удаленной платформ были доступны. Релиз 2016.3 принес возможность удаленно отлаживать с платформы Windows:

    • Приложения, запущенные на другой Windows-машине и собранные тем же инструментарием, из-под которого ведется отладка (MinGW / MinGW-w64 / Cygwin).

    • Приложения, запущенные на другой Windows-машине и собранные инструментарием отличным от того, из-под которого ведется отладка (собрано MinGW — отлаживается в Cygwin и т. п.). В этом случае необходимо в конфигурации в CLion указать корректное соответствие путей локальной и удаленной машины.

    • Приложения, запущенные на Linux-машине. Здесь вам понадобится кросс-платформенный GDB-отладчик (то есть стандартный в CLion не подойдет). О том, как его собрать, можно прочитать в нашем блоге. Конечно, потребуется и правильно настроенная конфигурация, с указанием пути до файла с отладочными символами и соответствия путей локальной и удаленной машины.

    Кстати, помимо удаленной отладки, в отладчике произошло целое множество исправлений. Так, например, CLion более не перезаписывает переменную окружения PYTHONPATH, что в частности позволяет отлаживать С-расширения для Python (Python C extension modules).

    Семантическая подсветка и не только


    Еще одна долгожданная возможность — семантическая подсветка! Сразу скажу, как включить: идем в настройки Editor | Color & Fonts | Language Defaults, находим там группу Semantic highlighting и ставим галочку Unique color for each parameter and local variable. Дальше можно настраивать цветовые диапазоны по собственному усмотрению или воспользоваться значениями по умолчанию.

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

    Как это работает в CLion:

    • Каждой локальной переменной и параметру присваивается свой цвет.
    • Внутри тела функции или лямбды CLion старается избежать повторов цветов.
    • Идентификаторы с одними и теми же именами получают одинаковый цвет.

    Ну, а выглядит это примерно так:

    image

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

    Представьте себе ситуацию, что файл с исходными кодами включен в сборку двух разных таргетов CMake. При этом настройки у этих таргетов отличаются, а в самом коде встречаются блоки условной компиляции, зависящие от этих настроек. Как же быть редактору кода в такой ситуации? Как правильно подсветить эти части кода, как искать случаи использования, как производить корректные рефакторинги кода? Ответ прост: выбрать настройки какого-то одного таргета и их использовать. Но какого? Нам представляется логичным, что того, над которым вы сейчас работаете и который собираете/отлаживаете в данный момент времени. Поэтому при переключении Run/Debug конфигурации, CLion 2016.3 автоматически переключает и resolve-контекст для файла:

    image

    Если все же это не то, чего вам хочется, воспользуйтесь ручным переключением resolve-контекста в правом нижнем углу редактора. Автоматическое переключение в таком случае будет отключено до следующего перезапуска IDE (но это скорее пока баг, чем фича).

    Unreal Engine


    Здесь на Хабре уже было несколько обсуждений разработки игр с использованием Unreal Engine в CLion. В рамках данного релиза мы решили посмотреть, как мы можем помочь пользователям в этом случае. А поводом стало появление стороннего плагина для Unreal Engine, который позволяет открыть проект в CLion, сгенерировав для него необходимые CMake-скрипты. Мы попробовали этот плагин и были приятно удивлены тем фактом, что получаемый CMake позволяет CLion быстрее проиндексировать проект, так как включает не все исходные коды игрового движка, а только необходимую часть.

    Обрадовавшись, мы существенно уменьшили время повторного переоткрытия уже проиндексированного проекта в CLion. А также наш коллега добавил плагин для автодополнения спецификаторов рефлекшена:

    image

    Подробный пост о том, как можно разрабатывать игры на базе Unreal Engine в CLion, можно прочитать в нашем блоге.

    Другие изменения


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

    • Генерация шаблона документации в формате Doxygen теперь умеет работать с шаблонами C++, генерируя для шаблонных параметров функций, структур и классов тег tparam:

      image

    • Диалог Find in Path теперь сохраняет настройки поиска (такие как выбранный скоуп, фильтр по именам файлов и пр.), вне зависимости от того, по какому пути вызывается данное действие.

    • Вместе со всей платформой IntelliJ в релиз CLion 2016.3 вошли улучшения в поддержке систем контроля версий, такие как sign-off коммиты, возможность откатить действие, на которое еще не вызвали push, возможность восстановить удаленную локальную ветку, улучшения производительности поиска по логам Git/Mercurial и другое.

    • А для пользователей macOS Sierra в релиз вошло критическое исправление скроллинга в редакторе, а также шрифт San Francisco (SF NS Text), который теперь используется по умолчанию в обеих темной (Darcula) и светлой (Default) теме.

    Ниже короткое демо на английском от Фила Нэша, нашего девелопер-адвоката:



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

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

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

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

      0

      Не удивив редактора CMake Cache, подумал что это баг, а оказывается это фитча. Хорошо что с выносом каталога сборки, для редактирования кеша можно cmake-gui использовать.

        0
        Мы сейчас еще планируем редактор CMake Cache добавить. Чтобы прямо в редакторе CLion была посветка и другие удобные возможности.
          0

          Без дерактора, как это сделано в cmake-gui или (мой комит) в Qt Creator, неудобно пользоваться фичей:



          А ещё, вышел CMake 3.7, а с ним появилась поддержка Server Mode. Начальная поддержка появилась в Qt Creator на мастер-ветке. У вас что-то в этом направлении планируется?

            0
            Мы как раз на Meeting C++ в Берлине на прошлой недели смогли пообщаться с разработчиками из Qt Creator, которые активно участвуют в разарботке CMake Server. Есть интересные идеи и планы на «попробовать». Когда что-то из этого выйдет в реальном релизе продукта пока сказать сложно. Расскажем, как появится понимание.
              +1

              Что-то пропустил, но там CMake сейчас занимается только Tobias Hunger :-) Но он как-то не совсем удобно сделал, сейчас мы с ним подпиливаем, я ему портирую свои изменения из CMakeProjectManager2. Главная идея: пока устройства дерева лучше чем в KDevelop никем не предложено. У вас просто дерево, в QtC только файлы из CMake — ни таргетов. В KDevelop удобнее сделано. Но Сервер у него уже работает (можно потыкать в git сборках).

                0
                Мы как раз с Тобиасом и общались активно, и несколько его коллег тоже подходили.
                CMake Server вот тоже обсуждали, мы планируем на него внимательно посмотреть в блажайшее время.
        0
        Действительно, CMake значительно ускорился, спасибо.

        Обидно, что в выходные оплатил подписку на год, а через пару дней вышла новая версия — у меня теперь в качестве постоянного фолбека 2016.2.
        Нельзя ли с этим что-то сделать? :)
          0
          Достаточно будет по окончании текущей продлить ее еще на месяц, чтобы получился год непрерывной оплаты, чтобы получить 2016.3 fallback.
          0
          Может неуместно, но спрошу: А планируется ли поддержка разработки для ARM например? Имею виду дебагеры периферии и прочие вкусности (см. например Кейл)
            0
            В целом, планируется какая-то поддержка. Но пока никаких конкретных вещей пообещать не могу. Описывайте свои случаи использования в нашем трекере. Мы обязательно над ними поразмыслим.
              0

              Просто сделайте возможность собирать Kit — по сути, группировка компиляторов, параметров сборки и т.п., которую можно использовать для конкретной билд-конфигурации. Этим можно решить вопрос сборки произвольным компилятором, а не дефолтным в системе.


              Упреждая: отписываться в трекере, скорее всего не буду, так как не пользуюсь продуктом (собственно из-за полной невозможности использования не для десктоп разработки в рамках компилятора по-умолчанию). Ну и показать кусок кода мне проще, чем описать полностью хотелку. Поэтому, пока, лучший выбор для меня — QtC ;-) А так — успехов!

                0

                Для кросс-компиляции есть CMAKE_TOOLCHAIN_FILE

                  0

                  Знаю. Более подробно — ниже.

                  0
                  Компилятор и сейчас можно использовать любой. Достаточно указать его в CMake.
                    0

                    Это понятно. И способа как минимум 4:


                    • Через инит-кеш (cmake -C initial-cache-script)
                    • Через переменные окружения
                    • Через тулчейн-файл
                    • Через параметры командной строки

                    А как среда, как парсер на это реагирует? У меня коллеги пытаются использовать Clion для работы над проектом, так от проблемы с тем что цепляются параметры (типа путей поиска заголовочников по-умолчанию) дефолтного компилятора, а не того, что в тулчейне прописан несколько страдают. Или IDE подцепляет параметры компилятора, sysroot, а они делают что-то не так?


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


                    Кроме того: настройка используемого cmake для данного набора (редко, но иногда нужная фича), отладчика.


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

                      0
                      Ага, кейс понятен. Мы его даже вот тут обсуждали. Можно оставить описание своего случая тамже.

                      Что касается первой части, то вообще и переменные окружения, и тулчейн файл, и параметры командной строки должны работать. Если проблемы, то лучше в саппорт или трекер написать — будем разбираться.
                        0
                        Что касается первой части, то вообще и переменные окружения, и тулчейн файл, и параметры командной строки должны работать.

                        Я правильно понял, что парсер должен смочь подхватить параметры компилятора (пути по умолчания для заголовочников, набор предобъявленных констант), если компилятор не системный, а задан, пусть — тулчейн-файлом?

                          0
                          Если компилятор корректно через CMake передается и он GCC/clang-base, то CLion сможет корректно получить всю информацию от компилятора, включая compiler-predefined macros и другое. Если же компилятор отличается или с каким-то хитрыми патчами, то нам известны случаи, когда есть проблемы в парсере. Но тут надо разбираться в каждом конкретном таком случае и лучше нас об этом известить через саппорт или трекер.
                            0

                            Большое спасибо за информацию!

              0
              Будет ли когда нибудь введена поддержка msvc? Как в QtCcreator к примеру.
                0
                Да, планируем. Пока не могу сказать, когда именно. Как решим, опубликуем планы на следующий релиз и там будет видно.
                  0
                  О, это шикарно. Спасибо большое за такой продукт.
                    0
                    Вам спасибо за отзыв.
                +2
                Хочу полную интеграцию с Qt и справкой!
                  0
                  qmake? UI designer? Что именно вы понимаете под интеграцией?
                    –1
                    Логично предположить, не меньше чем это сделано с visual studio.
                      +1
                      Как нам сейчас это видится:

                      qmake — планируем, но не ясно пока, когда именно
                      UI designer — вряд ли, наши инструменты нацелены на работу с кодом скорее

                      Qt Visual Studio Tools — штука удобная, не спорю. И, наверное, в качестве плагина к CLion ее сделать можно. Но в ближайшее время, вряд ли мы сможем выделить на это ресурсы команды. Но если кто-то в коммьюнити захочет что-то подобное сделать (API то открытый), мы будем рады помочь/подсказать по мере возможностей.
                  +1
                  А с проектами на Qt он позволяет работать?
                    0
                    нет, qmake пока не поддержан — CPP-318
                      +1
                      Я думаю что начать следовало бы не с QMake, а с других Qt-specific вещей:
                      — отображение Qt-ных типов в отладчике
                      — понимание парсером механизма 'signals/slots', правильное автодополнение для QObject::connect и подобных.
                      — редактор QML.
                        0
                        Да, эти задачи есть на самом деле в нашем трекере и мы про них помним. Спасибо за напоминание!
                          0
                          Да, перевести проект с QMake на CMake не очень сложно, а вот то, что дебажить приходится через QtCreator — это сильно мешает.
                            0
                            Да, реквест есть. Напомню команде про него еще раз — посмотрим, что и когда можно сделать. Сейчас могу предложить только workaround — загрузить pretty printers через .gdbinit. Они включены в поставку qt creator.
                        +2
                        Можно работать, но только если перевести проект на cmake.
                        +1
                        Скажите, а как теперь быстро переключаться между Debug и Release сборками?
                        Сейчас для каждого переключения нужно лезть в меню, переключать там И переключать таргет. Можно как-то настроить переключение в одном месте — выбором таргетов или, на худой конец, только переключением настроек (а таргет бы подхватывал нужный режим сам)?
                          0
                          К сожалению, быстро сейчас никак. Пришлось этим пожертвовать в угоду экономии места и времени загрузки CMake на проекте. Но мы планируем вернуть удобный способ переключения в рамках вот этого запроса.
                          0
                          Подскажите как мне справиться следующей проблемой:
                          Я разрабатываю с использованием JNI. Мне удобно было бы использовать один проект в двух ide (idea, clion), однако обе ide для своей работы создают папку .idea, что мешает работе одной из них. Что посоветуете?
                            +1
                            Да, проблема известная. К сожалению, хорошего решения предложить пока не могу. CLion когда-нибудь появится в виде плагина к IntelliJ IDEA, но пока на это нет свободных ресурсов команды. Да и проблему с конфликтами настроек разных наших IDE хотели поправить, но как-то тоже пока не сложилось. Спасибо, что напомнили о ней! Надо будет еще раз обсудить, что мы можем сделать.
                            +2

                            Вы клевые, спасибо, отличное обновление! Семантическую подсветку давно ждал, приятно видеть.


                            Одна мелочь, правда, есть. Я в прошлый раз в комментариях уже говорил, но как-то не договорил, так что ещё раз попробую.


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


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

                              0

                              А, и ещё. ninja-генератор для CMake поддерживаете, или только мейкфайлы?

                                0
                                Пока нет, но планируем добавить. Надеюсь, в каком-то из 2017.x сможем сделать.
                                0
                                Спасибо большое! Передам команде.

                                Про список таргетов — вообще идея прикольная. Вроде и правда что-то такое обсуждали уже тут. А закинете вот сюда с описанием что-как-зачем? Подумаем над запросом более обстоятельно.
                                  0
                                  0xd34df00d И поделитесь номером тикета, я плюсану. У меня тоже есть проект с >200 таргетов, и работать с ним, мягко говоря, не очень.
                                  0

                                  Пара фич, которые могут помочь (не решение, но возможный workaround):


                                  • В списках обычно работает live search, то есть если фокус на списке, то можно начать печатать подстроку или первые буквы из частей названия (отфильтруются все таргеты, кроме содержащих введенную подпоследовательность в названиии)
                                  • Action "Select Run/Debug configuration" можно назначить на хоткей, чтобы не кликать мышкой в combo-box, еще есть аналогичные экшены "Run..." и "Debug..." (выбрать конфигурацию и сразу запустить)
                                    0
                                    Ага, спасибо за идеи. Подумаем.
                                    0

                                    Хы, ты забыл сказать: как это сделано в KDevelop ;-) В QtC для CMake 3.7 сделали примерно так же — как же неудобно (пока?). Когда в LLVM открыл директорию с тестами, там овер-дохрена таргетов как вывалилось… Аж жуть.

                                    0
                                    CPP-3962 — Есть надежда увидеть исправление в обозримом будущем?
                                      0
                                      Да, как раз планируем после этого релиза посмотреть на эту проблему.
                                      0
                                      А нет планов на счет поддержки кастомного lldb, или хотя бы возможности передавать в текущим свой .lldbinit?
                                        0
                                        На какой платформе? Ну и интересен юз кейс. Что именно хочется таким образом получить?
                                          0
                                          Меня интересует mac. lldb очень плохо раскручивает классы Qt, вплоть до того, что содержимое даже QString не видно в переменных в отладке. Через initlldb это можно настроить, но как подсунуть во встроенный lldb эту настройку я не нашел
                                            0

                                            Data formatters из ~/.lldbinit должны подцепляться.

                                              0
                                              Как уже коллега мой ответил, .lldbinit должен сработать как workaround. А вообще про рендеринг Qt типов в отладчике есть реквест. Как раз напомнила про него команде.
                                          –1
                                          Не конкретизировались ли ваши планы по добавлению поддержки makefiles? Тикету на youtrack уже сто лет в обед. Третий по популярности, кстати.
                                            0
                                            Тикет и правда довольно популярный. Но пока что нам кажется, что другие задачи важнее. Например, изменения по CMake, которые критичны в частности для текущих пользователей продукта. Но мы все же надеемся в следующем году поразмысить над альтернативными проектными моделями в CLion, а может и даже возможностью открывать любой проект, в независимости от проектной модели.
                                            0
                                            Мне не очень часто доводится использовать CLion, но заметил, что с версии 2016.2 (именно с неё) в дебаге больше нельзя посмотреть массив по указателю целиком, отображается только первый элемент (пропал «Double click to see more items»).
                                            Возможно, я невнимательно прочитал список изменений в 2016.2, но хотелось бы узнать, почему вырезали эту возможность, есть ли какая-то альтернатива и вернут ли этот функционал в дальнейшем?
                                            Спасибо!
                                              0
                                              Похоже оно раньше работало «случайно» и сломалось в 2016.2. Запрос на такую возможность есть у нас в трекере. Там же описан workaround, пока не реализована возможность. Ну и посмотрим, куда можно в очереди эту задачу поставить — согласна, что важная штука. Спасибо!

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

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