- Как в плане языковой поддержки (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 и написали об этом целый отдельный пост.
- Множество других улучшений и изменений.
А теперь обо всем по порядку.
Поддержка C++: C++11 и C++14
Как вы, наверное, знаете (ведь у нас это спрашивают в комментариях под каждым постом про CLion), в CLion мы полагаемся на свой парсер, и активная работа над ним не затихает ни на минуту. В этот раз из существенных доработок стоит отметить несколько.
Во-первых, это поддержка пользовательских литералов. Мы долгое время не брались за эту задачу, но возрастающая популярность концепции встроенного типа и появление ее использований в std::chrono и других частях стандартной библиотеки привели нас к необходимости ее поддержки. Стоит отметить, что помимо уменьшения количества false-positive ошибок анализатора кода (которые были вызваны отсутствием поддержки пользовательских литералов) и всплывающего окна Quick Documentation (
Ctrl+Q на Lin/Win, F1 на macOS), которое теперь корректно отражает тип, CLion также позволяет переименовывать литералы, обновляя определение и все его использования:
Раз уж речь зашла об операторах, стоит отметить, что CLion умеет теперь искать случаи использования перегруженных операторов (кроме new и delete), что может быть особенно полезно при знакомстве с новым и неизвестным кодом, активно использующим эту возможность языка:
Еще одна причина множественных ошибок встроенного анализатора кода, которая была устранена в этом релизе, — исправления в поддержке overload resolution. Теперь CLion может правильно выбрать подходящего кандидата, а значит правильно показать неиспользуемый код, найти все использования, переименовать функцию или изменить ее сигнатуру, и т.д. А вместе с этим, среда разработки теперь укажет вам на ambiguous call или отсутствие подходящей функции для вызова — соответствующие инспекции добавлены в CLion 2016.3:
В целом наша команда расширилась, и в частности у нас появилось больше людей, занимающихся анализом кода. Благодаря этому релиз 2016.3 принес множество изменений в этой области. Например, анализ, полагающийся на вычисления sizeof(), стал платформо-зависимым. Мы также поправили ошибочное предупреждение о неиспользуемой переменной в случае нетривиального деструктора (что особенно важно для так называемой ‘guard’ idiom):
Кроме того, 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, в этой версии появилась возможность автодополнения для ускорения процесса написания кода:
Кто-то может здесь вспомнить, что в этой версии планировалось добавить шаблоны проектов, в частности для 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:
Обращаем внимание, что это пока работает только в случае, когда в качестве генератора использовались 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 старается избежать повторов цветов.
- Идентификаторы с одними и теми же именами получают одинаковый цвет.
Ну, а выглядит это примерно так:
Еще одно изменение, связанное с подсветкой кода, это автоматическое переключение resolve-контекста в редакторе при смене конфигурации. Давайте разберемся, зачем это может быть нужно.
Представьте себе ситуацию, что файл с исходными кодами включен в сборку двух разных таргетов CMake. При этом настройки у этих таргетов отличаются, а в самом коде встречаются блоки условной компиляции, зависящие от этих настроек. Как же быть редактору кода в такой ситуации? Как правильно подсветить эти части кода, как искать случаи использования, как производить корректные рефакторинги кода? Ответ прост: выбрать настройки какого-то одного таргета и их использовать. Но какого? Нам представляется логичным, что того, над которым вы сейчас работаете и который собираете/отлаживаете в данный момент времени. Поэтому при переключении Run/Debug конфигурации, CLion 2016.3 автоматически переключает и resolve-контекст для файла:
Если все же это не то, чего вам хочется, воспользуйтесь ручным переключением resolve-контекста в правом нижнем углу редактора. Автоматическое переключение в таком случае будет отключено до следующего перезапуска IDE (но это скорее пока баг, чем фича).
Unreal Engine
Здесь на Хабре уже было несколько обсуждений разработки игр с использованием Unreal Engine в CLion. В рамках данного релиза мы решили посмотреть, как мы можем помочь пользователям в этом случае. А поводом стало появление стороннего плагина для Unreal Engine, который позволяет открыть проект в CLion, сгенерировав для него необходимые CMake-скрипты. Мы попробовали этот плагин и были приятно удивлены тем фактом, что получаемый CMake позволяет CLion быстрее проиндексировать проект, так как включает не все исходные коды игрового движка, а только необходимую часть.
Обрадовавшись, мы существенно уменьшили время повторного переоткрытия уже проиндексированного проекта в CLion. А также наш коллега добавил плагин для автодополнения спецификаторов рефлекшена:
Подробный пост о том, как можно разрабатывать игры на базе Unreal Engine в CLion, можно прочитать в нашем блоге.
Другие изменения
В релизе CLion 2016.3 есть еще множество других изменений и правок, но, чтобы не затягивать, мы упомянем их лишь коротко:
- Генерация шаблона документации в формате Doxygen теперь умеет работать с шаблонами C++, генерируя для шаблонных параметров функций, структур и классов тег tparam:
- Диалог 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
Комментарии (55)
alexey-m-ukolov
23.11.2016 17:32Действительно, CMake значительно ускорился, спасибо.
Обидно, что в выходные оплатил подписку на год, а через пару дней вышла новая версия — у меня теперь в качестве постоянного фолбека 2016.2.
Нельзя ли с этим что-то сделать? :)
anastasiak2512
23.11.2016 18:09Достаточно будет по окончании текущей продлить ее еще на месяц, чтобы получился год непрерывной оплаты, чтобы получить 2016.3 fallback.
saw_tooth
23.11.2016 18:00Может неуместно, но спрошу: А планируется ли поддержка разработки для ARM например? Имею виду дебагеры периферии и прочие вкусности (см. например Кейл)
anastasiak2512
23.11.2016 18:08В целом, планируется какая-то поддержка. Но пока никаких конкретных вещей пообещать не могу. Описывайте свои случаи использования в нашем трекере. Мы обязательно над ними поразмыслим.
monah_tuk
27.11.2016 17:14Просто сделайте возможность собирать Kit — по сути, группировка компиляторов, параметров сборки и т.п., которую можно использовать для конкретной билд-конфигурации. Этим можно решить вопрос сборки произвольным компилятором, а не дефолтным в системе.
Упреждая: отписываться в трекере, скорее всего не буду, так как не пользуюсь продуктом (собственно из-за полной невозможности использования не для десктоп разработки в рамках компилятора по-умолчанию). Ну и показать кусок кода мне проще, чем описать полностью хотелку. Поэтому, пока, лучший выбор для меня — QtC ;-) А так — успехов!
anastasiak2512
27.11.2016 23:02Компилятор и сейчас можно использовать любой. Достаточно указать его в CMake.
monah_tuk
28.11.2016 05:10Это понятно. И способа как минимум 4:
- Через инит-кеш (cmake -C initial-cache-script)
- Через переменные окружения
- Через тулчейн-файл
- Через параметры командной строки
А как среда, как парсер на это реагирует? У меня коллеги пытаются использовать Clion для работы над проектом, так от проблемы с тем что цепляются параметры (типа путей поиска заголовочников по-умолчанию) дефолтного компилятора, а не того, что в тулчейне прописан несколько страдают. Или IDE подцепляет параметры компилятора, sysroot, а они делают что-то не так?
Ну и остаётся вопрос удобства, когда таких тулчейнов несколько (и не обязательно для кросс-сборки, просто версии компилятор разные) и нужно для нескольких проектов иметь возможность меж ними переключаться. Как я понимаю, сейчас можно проект настроить только на что-то одно (даже указав компилятор и прочие параметры одним из вышеперечисленных способов).
Кроме того: настройка используемого cmake для данного набора (редко, но иногда нужная фича), отладчика.
Ну и билд конфигурации с разными параметрами сборки тоже не хватает, с возможностью между ними переключаться.
anastasiak2512
28.11.2016 13:13Ага, кейс понятен. Мы его даже вот тут обсуждали. Можно оставить описание своего случая тамже.
Что касается первой части, то вообще и переменные окружения, и тулчейн файл, и параметры командной строки должны работать. Если проблемы, то лучше в саппорт или трекер написать — будем разбираться.monah_tuk
28.11.2016 14:05Что касается первой части, то вообще и переменные окружения, и тулчейн файл, и параметры командной строки должны работать.
Я правильно понял, что парсер должен смочь подхватить параметры компилятора (пути по умолчания для заголовочников, набор предобъявленных констант), если компилятор не системный, а задан, пусть — тулчейн-файлом?
anastasiak2512
28.11.2016 15:59Если компилятор корректно через CMake передается и он GCC/clang-base, то CLion сможет корректно получить всю информацию от компилятора, включая compiler-predefined macros и другое. Если же компилятор отличается или с каким-то хитрыми патчами, то нам известны случаи, когда есть проблемы в парсере. Но тут надо разбираться в каждом конкретном таком случае и лучше нас об этом известить через саппорт или трекер.
Warezovvv
23.11.2016 18:09Будет ли когда нибудь введена поддержка msvc? Как в QtCcreator к примеру.
anastasiak2512
23.11.2016 18:11Да, планируем. Пока не могу сказать, когда именно. Как решим, опубликуем планы на следующий релиз и там будет видно.
Boctopr
23.11.2016 18:59+2Хочу полную интеграцию с Qt и справкой!
anastasiak2512
23.11.2016 23:01qmake? UI designer? Что именно вы понимаете под интеграцией?
Boctopr
23.11.2016 23:15-1Логично предположить, не меньше чем это сделано с visual studio.
anastasiak2512
23.11.2016 23:24+1Как нам сейчас это видится:
qmake — планируем, но не ясно пока, когда именно
UI designer — вряд ли, наши инструменты нацелены на работу с кодом скорее
Qt Visual Studio Tools — штука удобная, не спорю. И, наверное, в качестве плагина к CLion ее сделать можно. Но в ближайшее время, вряд ли мы сможем выделить на это ресурсы команды. Но если кто-то в коммьюнити захочет что-то подобное сделать (API то открытый), мы будем рады помочь/подсказать по мере возможностей.
Alert123
23.11.2016 22:56+1А с проектами на Qt он позволяет работать?
anastasiak2512
23.11.2016 22:56нет, qmake пока не поддержан — CPP-318
dion
24.11.2016 12:54+1Я думаю что начать следовало бы не с QMake, а с других Qt-specific вещей:
— отображение Qt-ных типов в отладчике
— понимание парсером механизма 'signals/slots', правильное автодополнение для QObject::connect и подобных.
— редактор QML.anastasiak2512
24.11.2016 13:34Да, эти задачи есть на самом деле в нашем трекере и мы про них помним. Спасибо за напоминание!
alexey-m-ukolov
24.11.2016 20:32Да, перевести проект с QMake на CMake не очень сложно, а вот то, что дебажить приходится через QtCreator — это сильно мешает.
anastasiak2512
24.11.2016 23:45Да, реквест есть. Напомню команде про него еще раз — посмотрим, что и когда можно сделать. Сейчас могу предложить только workaround — загрузить pretty printers через .gdbinit. Они включены в поставку qt creator.
metopa
23.11.2016 22:57+1Скажите, а как теперь быстро переключаться между Debug и Release сборками?
Сейчас для каждого переключения нужно лезть в меню, переключать там И переключать таргет. Можно как-то настроить переключение в одном месте — выбором таргетов или, на худой конец, только переключением настроек (а таргет бы подхватывал нужный режим сам)?anastasiak2512
23.11.2016 22:58К сожалению, быстро сейчас никак. Пришлось этим пожертвовать в угоду экономии места и времени загрузки CMake на проекте. Но мы планируем вернуть удобный способ переключения в рамках вот этого запроса.
Tim06ka
23.11.2016 22:58Подскажите как мне справиться следующей проблемой:
Я разрабатываю с использованием JNI. Мне удобно было бы использовать один проект в двух ide (idea, clion), однако обе ide для своей работы создают папку .idea, что мешает работе одной из них. Что посоветуете?anastasiak2512
23.11.2016 23:01+1Да, проблема известная. К сожалению, хорошего решения предложить пока не могу. CLion когда-нибудь появится в виде плагина к IntelliJ IDEA, но пока на это нет свободных ресурсов команды. Да и проблему с конфликтами настроек разных наших IDE хотели поправить, но как-то тоже пока не сложилось. Спасибо, что напомнили о ней! Надо будет еще раз обсудить, что мы можем сделать.
0xd34df00d
24.11.2016 00:01+2Вы клевые, спасибо, отличное обновление! Семантическую подсветку давно ждал, приятно видеть.
Одна мелочь, правда, есть. Я в прошлый раз в комментариях уже говорил, но как-то не договорил, так что ещё раз попробую.
Вот представьте себе, что у вас есть проект, в котором под пару сотен подпроектов со своими CMakeLists.txt, каждый из которых задаёт от двух до десятка таргетов. Окошко выбора в этом случае очень неудобное и имеет очень длинный скролл: например. Поэтому каждый раз, когда я понимаю, что сейчас мне надо будет выбрать другой таргет, я грущу и иду пить чай вместо того, чтобы продуктивно работать.
Так вот, было бы очень круто, если бы список таргетов, задаваемый конкретным CMakeLists.txt, был бы где-то рядом с этим CMakeLists.txt (например, отображался в виде этаких псевдофайлов в дереве слева прям под папками, или по клику на папку, содержащую CMakeLists.txt). Как смотрите на такое дело?
0xd34df00d
24.11.2016 00:05А, и ещё. ninja-генератор для CMake поддерживаете, или только мейкфайлы?
anastasiak2512
24.11.2016 00:30Пока нет, но планируем добавить. Надеюсь, в каком-то из 2017.x сможем сделать.
anastasiak2512
24.11.2016 00:30Спасибо большое! Передам команде.
Про список таргетов — вообще идея прикольная. Вроде и правда что-то такое обсуждали уже тут. А закинете вот сюда с описанием что-как-зачем? Подумаем над запросом более обстоятельно.metopa
24.11.2016 11:110xd34df00d И поделитесь номером тикета, я плюсану. У меня тоже есть проект с >200 таргетов, и работать с ним, мягко говоря, не очень.
dkozh
24.11.2016 12:47Пара фич, которые могут помочь (не решение, но возможный workaround):
- В списках обычно работает live search, то есть если фокус на списке, то можно начать печатать подстроку или первые буквы из частей названия (отфильтруются все таргеты, кроме содержащих введенную подпоследовательность в названиии)
- Action "Select Run/Debug configuration" можно назначить на хоткей, чтобы не кликать мышкой в combo-box, еще есть аналогичные экшены "Run..." и "Debug..." (выбрать конфигурацию и сразу запустить)
monah_tuk
27.11.2016 17:20Хы, ты забыл сказать: как это сделано в KDevelop ;-) В QtC для CMake 3.7 сделали примерно так же — как же неудобно (пока?). Когда в LLVM открыл директорию с тестами, там овер-дохрена таргетов как вывалилось… Аж жуть.
erok
24.11.2016 12:47А нет планов на счет поддержки кастомного lldb, или хотя бы возможности передавать в текущим свой .lldbinit?
anastasiak2512
24.11.2016 12:50На какой платформе? Ну и интересен юз кейс. Что именно хочется таким образом получить?
erok
24.11.2016 15:09Меня интересует mac. lldb очень плохо раскручивает классы Qt, вплоть до того, что содержимое даже QString не видно в переменных в отладке. Через initlldb это можно настроить, но как подсунуть во встроенный lldb эту настройку я не нашел
anastasiak2512
24.11.2016 23:47Как уже коллега мой ответил, .lldbinit должен сработать как workaround. А вообще про рендеринг Qt типов в отладчике есть реквест. Как раз напомнила про него команде.
Spym
29.11.2016 00:11-1Не конкретизировались ли ваши планы по добавлению поддержки makefiles? Тикету на youtrack уже сто лет в обед. Третий по популярности, кстати.
anastasiak2512
29.11.2016 00:25Тикет и правда довольно популярный. Но пока что нам кажется, что другие задачи важнее. Например, изменения по CMake, которые критичны в частности для текущих пользователей продукта. Но мы все же надеемся в следующем году поразмысить над альтернативными проектными моделями в CLion, а может и даже возможностью открывать любой проект, в независимости от проектной модели.
vientooscuro
01.12.2016 12:46Мне не очень часто доводится использовать CLion, но заметил, что с версии 2016.2 (именно с неё) в дебаге больше нельзя посмотреть массив по указателю целиком, отображается только первый элемент (пропал «Double click to see more items»).
Возможно, я невнимательно прочитал список изменений в 2016.2, но хотелось бы узнать, почему вырезали эту возможность, есть ли какая-то альтернатива и вернут ли этот функционал в дальнейшем?
Спасибо!
RPG18
Не удивив редактора CMake Cache, подумал что это баг, а оказывается это фитча. Хорошо что с выносом каталога сборки, для редактирования кеша можно cmake-gui использовать.
anastasiak2512
Мы сейчас еще планируем редактор CMake Cache добавить. Чтобы прямо в редакторе CLion была посветка и другие удобные возможности.
monah_tuk
Без дерактора, как это сделано в cmake-gui или (мой комит) в Qt Creator, неудобно пользоваться фичей:
А ещё, вышел CMake 3.7, а с ним появилась поддержка Server Mode. Начальная поддержка появилась в Qt Creator на мастер-ветке. У вас что-то в этом направлении планируется?
anastasiak2512
Мы как раз на Meeting C++ в Берлине на прошлой недели смогли пообщаться с разработчиками из Qt Creator, которые активно участвуют в разарботке CMake Server. Есть интересные идеи и планы на «попробовать». Когда что-то из этого выйдет в реальном релизе продукта пока сказать сложно. Расскажем, как появится понимание.