Привет! Год потихоньку подходит к концу, кто-то уже готовится к праздничным мероприятиям, а кто-то еще старается завершить все задуманное. А мы вот выпустили третий за этот год релиз нашей кросс-платформенной 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 и написали об этом целый отдельный пост.
- Множество других улучшений и изменений.
А теперь обо всем по порядку.
Поддержка 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
Автор: JetBrains
