Реліз 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

Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.