GCC 16 покажет ошибки в браузере — компилятор перестал быть занудой!

GCC 16: диагностика ошибок по-новому, теперь и в HTML

Если вы когда-нибудь ловили себя на том, что тупо пялились в километровый вывод компилятора, пытаясь понять, где же именно всё пошло не так — добро пожаловать в клуб. GCC (тот самый GNU Compiler Collection) умеет устраивать настоящий фестиваль ошибок, где каждая строчка — загадка. Но, кажется, в следующем году нас ждёт кое-что интересное: GCC 16 принесёт новый формат вывода диагностик — теперь даже в HTML. Да-да, ошибки можно будет смотреть в браузере, со всеми плюшками в виде подсветки, форматирования и навигации. Звучит, как минимум, удобнее, чем серый текст в терминале, правда?

Эта новинка — заслуга Дэвида Малкольма из Red Hat. Если вы следите за разработкой GCC, то наверняка знаете это имя: он уже не первый год улучшает диагностику компилятора, и делает это с какой-то почти буддийской настойчивостью. В этот раз он рассказал о грядущих изменениях на конференции GNU Tools Cauldron 2025 в Порту, Португалия (вот уж символично — «котёл» инструментов, где варятся все эти технологические новшества).

HTML вместо стен текста

Итак, что же там нового? Главное — HTML-вывод ошибок. Раньше GCC умел отдавать диагностику в JSON, но, как признались разработчики, JSON — это, конечно, удобно для машин, но людям читать больно. Поэтому в GCC 16 решили пойти по пути красоты и читаемости: теперь можно будет добавить флаг -fdiagnostics-add-output=experimental-html, и компилятор создаст HTML-страницу с результатами сборки.

Представьте: вы открываете браузер и видите не скучный лог, а аккуратную страницу, где ошибки подсвечены, можно щёлкнуть и перейти к нужному месту, а подсказки оформлены человечески. Честно говоря, когда я впервые увидел пример этой фичи, первая мысль была: «А почему так не сделали десять лет назад?» Ведь сколько часов программисты проводят, разбирая ошибки сборки, и сколько нервов это стоит — не пересчитать.

Сейчас HTML-диагностика пока в статусе experimental, но уже выглядит многообещающе. Малкольм даже показал пример страницы — с цветами, ссылками и подсказками. Конечно, пока всё немного «сырое», но направление верное. И если команда GCC не забросит идею, это реально может упростить жизнь тем, кто работает с большими проектами, где на один чих компилятора приходится десяток предупреждений.

SARIF вместо JSON — и зачем это нужно

А вот ещё интересный момент: JSON-формат для вывода диагностик решили заменить на SARIF. Кто не в курсе — SARIF (Static Analysis Results Interchange Format) — это такой универсальный формат, который придумали, чтобы разные анализаторы кода могли обмениваться данными. Его поддерживают VS Code, GitHub и другие инструменты. То есть теперь GCC будет говорить на «языке» современных IDE и систем анализа. Можно будет подхватывать ошибки прямо в редакторе, без всяких костылей и сторонних скриптов.

На первый взгляд, мелочь. Но на практике — огромный шаг к нормальной интеграции GCC в экосистему разработчика. Ведь сколько лет мы жили с тем, что «если хочешь удобства — иди к Clang». Теперь, возможно, этот аргумент начнёт терять силу.

-fanalyzer: теперь ещё умнее

Другая тема, которую Малкольм тоже затронул — это улучшения для опции -fanalyzer. Если коротко, это встроенный статический анализатор кода в GCC, который умеет находить утечки памяти, необработанные значения, ошибки логики и всё такое. Работает, как детектив: прослеживает, как переменные бегают по коду, и где они могли «потеряться».

В GCC 16 этот анализатор станет умнее и полезнее, особенно для C++. Говорят, улучшат понимание шаблонов, исключений и других тонких мест, где раньше анализатор просто сдавался. А ещё его вывод теперь можно будет получать в SARIF — то есть удобно просматривать результаты прямо в IDE или CI-инструментах. Это уже звучит не просто как «опция для энтузиастов», а как инструмент, который можно включать на продакшн-проектах.

libdiagnostics и другие внутренние штуки

Параллельно идёт работа и над внутренней библиотекой libdiagnostics. Звучит скучно, но именно она отвечает за то, как компилятор сообщает об ошибках: где указывает файл, строку, контекст и т.д. В новой версии она будет точнее работать с «логическими локациями» (когда ошибка не в одной конкретной строке, а где-то между макросами и вызовами). Короче, теперь меньше шансов, что вы будете искать баг там, где его нет.

Кстати, ходят слухи, что разрабатывается и интеграция GCC с IDE через JSON-RPC. Пока это в статусе эксперимента, но если заработает — можно будет получать подсказки и диагностику в реальном времени прямо во время набора кода. Как у Clangd, только с GNU-шным духом.

Немного философии напоследок

Иногда кажется, что разработчики GCC — это такие инженеры старой школы: им главное, чтобы всё работало, а удобство — потом. Но последние пару лет в проекте явно идёт движение в сторону человеческого интерфейса. Ведь компилятор — это не просто программа, а инструмент общения между человеком и машиной. И чем понятнее он говорит, тем меньше мы, программисты, срываемся на крик.

Я вот, например, помню, как однажды потратил полдня, пытаясь понять, почему у меня не компилируется код, а в итоге оказалось, что я просто не закрыл скобку. Вот где бы мне тогда пригодилась подсветка в HTML — с нормальными пояснениями и навигацией. А то в терминале такие ошибки выглядят как древнеегипетская рукопись.

Что всё это значит для нас

Если вы используете GCC в повседневной работе — особенно для C++ — то GCC 16 обещает быть заметным апдейтом. Да, пока HTML-диагностика экспериментальная, SARIF ещё не везде поддерживается, а IDE-интеграция в зачатке. Но вектор понятен: компилятор становится более дружелюбным, гибким и визуальным. И это круто.

Так что если вы любите эксперименты (а кто из разработчиков их не любит?), попробуйте включить новый HTML-вывод, когда выйдет GCC 16. А потом откройте браузер, налейте себе кофе — и наслаждайтесь видами своих ошибок в HD-качестве. Потому что, как ни крути, мы всё равно будем ошибаться. Но теперь — красиво.

Те, кому интересна работа по диагностике, проводимая в рамках подготовки к выпуску компилятора GCC 16 в следующем году, могут узнать больше из презентации на GNU Tools Cauldron 2025.