Компиляция без предупреждений — что случилось в Linux-сообществе

Пару недель назад Линус Торвальдс активировал флаг -Werror для всех сборок ядра. Мнения сообщества касательно этого решения разделились. Против даже высказался разработчик фронтенда Clang и фреймворка LLVM. Обсуждаем ситуацию.

Warning’и не нужны

Год назад Линус Торвальдс в рассылке LKML рассказал ^[1], что перешел на gcc-10, и новые предупреждения компилятора (описания которых порой занимают целые абзацы) мешают работать над ядром — среди них сложно искать критические ошибки. Так, создатель Linux решил отключить warning’и, не представляющие интереса на конкретном этапе работы — например, restrict, stringop-overflow, array-bounds и zero-length-bounds. Но в начале сентября он предпринял довольно радикальный шаг в другом направлении и изменил ^[2] параметры компиляции кода ядра Linux для мейнтейнеров. Торвальдс активировал флаг -Werror в Makefile, благодаря которому компилятор начал интерпретировать ^[3] любое предупреждение как ошибку. Таким образом он хотел улучшить ^[4] качество получаемых pull-запросов.

Справедливости ради стоит заметить, что соответствующая опция также появилась в Kconfig (то есть -Werror можно было отключить), но инициатива все равно разделила ИТ-сообщество на два лагеря. Одни посчитали, что нововведение серьезно повысит качество кодовой базы. Другие заметили, что оно не принесет ничего, кроме «головной боли», а ситуацию с большим количеством предупреждений нужно решать ^[5] на стороне компиляторов — например, добавлением нескольких категорий фильтрации ошибок. Далее мы рассмотрим аргументы обеих сторон.

Сомнительное решение

Один из резидентов Hacker News в тематическом треде отметил ^[6], что обработка warning’ов при разработке программного обеспечения — это хорошая практика. Более того, предупреждения, касающиеся старого кода, могут скрывать ^[7] реальные проблемы и баги, требующие срочного исправления. Это — одна из причин, по которой флаг -Werror используют ^[8] многие разработчики. Однако можно привести контраргумент — большинство подобных проектов менее масштабные, чем Linux. В этом случае обработка всех предупреждений может оказаться не просто сложной, но невыполнимой задачей.

При этом на практике не все предупреждения компилятора одинаково полезны. Зачастую они не помогают программистам, а мешают и даже подталкивают к исправлениям правильного кода — эту тему еще несколько лет назад обсуждали на Хабре ^[9]. Чаще всего проблема возникает ^[10] при работе со старой кодовой базой. Разработчики компиляторов добавляют новые предупреждения, которых могло не быть во время написания оригинального кода.

Против решения Линуса Торвальдса также высказался Ник Десанье из Google, работающий над Clang ^[11] и LLVM ^[12]. Он даже предложил патч ^[13], возвращающий флаг в изначальное состояние. По словам ^[14] инженера, коллегам стоит внимательнее тестировать код на различных конфигурациях и серьезнее относиться к предупреждениям компилятора, но -Werror — слишком кардинальный шаг. Одним из немногих кейсов, когда этот флаг способен принести пользу, является защита «чистой» кодовой базы от ошибок. Эту точку зрения поддержал ^[15] коллега Ника — по его мнению, старые предупреждения в малоиспользуемых подсистемах не должны мешать разработке и тестированию целого ядра.

Найденный компромисс

В начале недели Линус Торвальдс признался ^[16], что «погорячился» с включением -Werror, и сообществу удалось прийти к компромиссу. Теперь соответствующий флаг будут использовать только для билдов COMPILE_TEST ^[17], которые часто проводят с использованием CI-систем. Соответствующий коммит Линус уже опубликовал ^[18]. Можно с уверенностью сказать, что вопрос не будут поднимать в ближайшем будущем — по крайней мере, до выпуска Linux kernel 5.15, намеченного ^[19] на ноябрь.

По словам разработчиков, это не самый масштабный релиз, но даже он включает несколько интересных компонентов. Например, в его состав войдет ^[20] новая реализация файловой системы NTFS от Paragon Software. Старый драйвер не обновлялся уже много лет, а новый привнесет дополнительную функциональность — расширенные атрибуты файлов, режим сжатия данных, списки доступа (ACL). Также можно ожидать появления драйверов для DMA ^[21]-движка PassThru от AMD.

Свежие посты из нашего блога на Хабре:

• QUIC стал RFC, но как дела с перспективами — обсуждаем мнения ^[22]

• Новый открытый VPN-протокол — на что обратить внимание ^[23]

• Что ждет Wi-Fi: три новых стандарта до 2024-го ^[24]

Особенности работы интернет-провайдеров — в нашем корп. блоге:

• Нужно ли российским провайдерам блокировать пиратский контент ^[25]

• Оптимизация сетей провайдера — как сделать все правильно ^[26]

• На что «пересесть» после ACCEL-PPP ^[27]