LINUX.ORG.RU

IWYU 0.21

 , iwyu


1

3

Вышел релиз IWYU (или include-what-you-use), программы позволяющей находить избыточные и предлагать недостающие #include в вашем коде на C/C++.

«Включать то, что используешь» означает следующее: для каждого символа (типа, переменной, функции или макроса), используемого в foo.cc, либо foo.cc, либо foo.h должны подключать .h-файл, экспортирующий объявление этого символа. Инструмент include-what-you-use – это программа для анализа #include исходных файлов с целью поиска нарушений этого подхода и выдачи рекомендаций для исправления. Программа использует библиотеки Clang и обычно релиз означает совместимость с новой версией Clang.

Основная цель include-what-you-use - удаление лишних #include. Для этого необходимо выяснить, какие #include не нужны в данном файле (как для .cc, так и для .h), и по возможности заменить #include на предварительное объявление.

Основные изменения

  • Совместимость с Clang 17.
  • Улучшен анализ псевдонимов типов (typedef и using).
  • Улучшен анализ псевдонимов пространств имен (namespace xyz = foobar).
  • Улучшена поддержка развернутых предварительных деклараций (typedef struct Foo Bar;).
  • Улучшить обработку «автокаста» и возвращаемых типов функций, особенно при работе со сложными шаблонными типами.
  • Добавлена новая прагма IWYU: always_keep, позволяющая пометить заголовок, что он всегда должен сохраняться, где бы он ни был включен.
  • Автоматическое использование сопоставлений для builtins libc++, если libc++ является активной стандартной библиотекой.
  • Улучшение сопоставлений для заголовков libc++ и posix.

>>> Подробности



Проверено: hobbit ()

Ответ на: комментарий от hobbit

Мысль интересная относительно транзитивности, но, при существующем препроцессоре, единица (ключевое слово — она одна!) трансляции формируется методом тупой замены директивы #include на содержимое включаемого файла. Ну с поправкой на контроль рекурсивных директив #include, отработкой защитных #ifndef _МОЯ_ХЕРНЯ_ИНКЛЮДЕД и прочего #pragma once. И только после этого, единица трансляции передается компилятору. Компилятор располагает информацией о том, где и что определено (хотя бы, для отладочных символов), но и это все. На что мы можем надеяться, так это на то, что разработчик библиотек предусмотрел некую версионность своих творений и документировал границы совместимости. Отсюда всякие ворнинги о том, что такой-то вызов устарел, например, или начиная с такой-то версии есть новый вызов инициализации. Примеров тому масса, думаю, ты сам на такое налетал (см. хоть код ядра с его вечными #if LINUX_VERSION_CODE >= KERNEL_VERSION(x,y,z)).

Я не думаю, что у анализатора есть хоть какие-то механизмы анализа транзитивности (ибо «единица трансляции»). Пока у тебя нет средств языка определить контракт на вызов, проблема совместимости библиотек будет. Все попытки в C++ придумать концепции(https://en.cppreference.com/w/cpp/concepts) и метапрграммирование (https://en.cppreference.com/w/cpp/meta) пока выглядят костылями.

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

Тут вон из Poco Library ошибки OpenSSL при создании SSL-контекста-то не вытащишь, какие тут границы совместимости. OpenSSL вообще на C написан и динамически загружается. Поэтому нарушения контракта только в рантайме понять можно. И то, если можно.

Если тулза сможет найти лишние или избыточные включения в твоем коде (а тут важен scope), то оно уже хорошо. И да, модули с С++20 — это действительно попытка разбить исходный файл на несколько единиц трансляции, именно для борьбы с транзитивностью. Насколько эффективная — не знаю. А главное, почти бесполезная, ибо никто не будет переписывать существующий код.

gns ★★★★★
()
Ответ на: комментарий от gns

Насколько эффективная — не знаю

Перцы из Facebook, которые эти модули активно продвигали, говорят, что скорость сборки увеличилась в разы.

А главное, почти бесполезная, ибо никто не будет переписывать существующий код.

Правильно. Существующий код будет нахрен выкинут.

hateyoufeel ★★★★★
()
Ответ на: комментарий от hateyoufeel

Ну только что скорость сборки, да. Но это слабое оправдание.

Правильно. Существующий код будет нахрен выкинут.

С чего начнем? :)))

gns ★★★★★
()
Ответ на: комментарий от gns

Ну только что скорость сборки, да. Но это слабое оправдание.

Да нет, это основная причина, зачем эти мудули вообще нужны. Потому что сейчас какой-нибудь сраный Libreoffice собирается по два-три часа, и это просто позор.

Вот так вот сделал ты небольшое изменение в какой-нибудь из корневых модулей, от которых всё зависит, и можно идти домой, потому что сборка будет только к вечеру, если не завтра. Весело, да?

hateyoufeel ★★★★★
()
Последнее исправление: hateyoufeel (всего исправлений: 1)
Ответ на: комментарий от hateyoufeel

Ну, если офис разобьют на модули и выловят все ошибки, с этим связанные, то оно и хорошо. Интересно будет посмотреть на результаты. Прошлые попытки реализовать precompiled headers чот не впечатлили.

gns ★★★★★
()
Ответ на: комментарий от hateyoufeel

говорят, что скорость сборки увеличилась в разы

Охотно верю.

hobbit ★★★★★
()
Ответ на: комментарий от gns

Я не думаю, что у анализатора есть хоть какие-то механизмы анализа транзитивности (ибо «единица трансляции»). Пока у тебя нет средств языка определить контракт на вызов, проблема совместимости библиотек будет.

Ну если написать анализатор поумнее, который не просто подражает компилятору, а делает какие-то предположения относительно того, как ДОЛЖЕН выглядеть код, задача выглядит подъёмной. Статические же анализаторы кода этим занимаются, вот не знаю, правда, натаскивал ли кто-либо их на проблему транзитивности.

hobbit ★★★★★
()
Ответ на: комментарий от hobbit

Ну если написать анализатор поумнее, который не просто подражает компилятору, а делает какие-то предположения относительно того, как ДОЛЖЕН выглядеть код,

Должен — это когда взял и не отдал :) Ой чую я упор в проблему останова в подобных рассуждениях, ой чую... :)

Кароч, список эвристик в студию, потом обсудим. Пока я не вижу даже подходов к решению этой проблемы.

gns ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.