#compiler

[Часть 1/2]
Как работает статический анализ кода? Обзор clang-tidy 🧹🧹🧹

clang-tidy нужен, чтобы поправлять исходники C++ (или хотя бы выводить warning-и). В других языках такой инструмент называется "linter" и часто встроен в сам язык и/или стандартизирован (например PEP8 в Python).

clang-tidy умеет диагностировать разные баги, устаревший код, подозрительные паттерны кода. Возможных проверок очень много (список). Например, проверка на неэффективный push_back в векторе: ссылка. На своем коде можно исполнять любые проверки.

Несмотря на то, что проверок уже почти 300 штук, все равно можно придумать идею для своих проверок.

✏️ Описание проверки
Я придумал свою проверку. Как до C++17 объявлялись константные переменные? По-правильному примерно так:
// в .h-файле:
extern const std::string DVCC_DVVC_BLOCK_TYPE_NAME;
// в .cpp-файле:
const std::string DVCC_DVVC_BLOCK_TYPE_NAME = "Dolby Vision configuration";

Вообще можно в .h-файле определить константную переменную, и это скомпилируется, но будет плохо, потому что const-переменные по умолчанию static. Это значит что каждый .cpp-файл будет иметь дело с локальной копией одной и той же переменной 👻
// так плохо! в .h-файле:
const std::string DVCC_DVVC_BLOCK_TYPE_NAME = "Dolby Vision configuration";

Начиная с C++17 можно записывать значения подобных переменных не отходя от кассы:
// в .h-файле
inline const std::string DVCC_DVVC_BLOCK_TYPE_NAME = "Dolby Vision configuration";

И вот моя проверка должна находить первые два плохие случая и предлагать писать по-новому, как в третьем случае.

✏️ Как это работает в коде
Я это сделал в феврале (тут pull request), но до прода не дотащил, так как ревью медленно проходит (примерно раз в три месяца).

Посмотрим по коду, как эта вещь работает ⚙️ Сначала надо ограничить возможные языки - нужен C++17 или выше:
bool isLanguageVersionSupported(const LangOptions &LangOpts) const override {
return LangOpts.CPlusPlus17;
}

Clang переводит исходники в AST (Absract Syntax Tree). Проверки работают исключительно на AST Matchers - это конструкция для нахождения нужных нод дерева. AST Matchers пишутся легко, но из-за сложности стандарта они постоянно патчатся, чтобы покрыть крайние случаи 🐸

Надо придумать и "зарегистрировать" AST Matcher для интересующих нас нод. Это должны быть объявления переменных, причем глобальные константные не-inline переменные на уровне файла (т.е. не внутри класса).

Достаточно ли этого? Нет... Если посмотреть Стандарт, то окажется, что из рассмотрения нужно выкинуть переменные внутри анонимного namespace (их точно бесполезно исправлять), шаблонные переменные (они неявно inline), volatile переменные (тут не помню почему), а также переменные внутри extern "C" на всякий случай:
auto NonInlineConstVarDecl =
varDecl(hasGlobalStorage(),
hasDeclContext(anyOf(translationUnitDecl(),
namespaceDecl())), // is at file scope
hasType(isConstQualified()), // const-qualified
unless(anyOf(
isInAnonymousNamespace(), // not within an anonymous namespace
isTemplateVariable(), // non-template
isInline(), // non-inline
hasType(isVolatileQualified()), // non-volatile
isExternC() // not "extern C" variable
)));

Регистрируем матчер для поиска extern объявлений (AST Matchers можно смешивать):
Finder->addMatcher(varDecl(NonInlineConstVarDecl, isExternallyVisible())
.bind("extern-var-declaration"),
this);

Регистрируем матчер для поиска не-inline определений:
Finder->addMatcher(varDecl(NonInlineConstVarDecl, isDefinition(),
unless(isExternallyVisible()))
.bind("non-inline-var-definition"),
this);