В этой статье я расскажу о новой библиотеке (и утилите) статического анализа go-ruleguard, которая адаптирует gogrep для использования внутри линтеров. Отличительная особенность: правила статического анализа вы описываете на особом Go-подобном DSL, который на старте ruleguard превращается в набор диагностик. Возможно, это один из самых легко конфигурируемых инструментов для реализации кастомных инспекций для Go. В качестве бонуса, мы поговорим об go/analysis и его предшественниках. Для Go существует множество линтеров, некоторые из которых можно расширять. Обычно для расширения линтера вам требуется написать Go код, использующий специальное API линтера. Есть два основных пути: Go plugins и монолит. Монолит подразумевает, что все проверки (в том числе ваши личные) доступны на этапе компиляции. revive требует включения новых проверок в своё ядро для расширения. go-critic вдобавок к этому умеет в плагины, что позволяет собирать расширения независимо от основного кода. Оба эти подхода подразумевают, что вы реализуете манипуляции над go/ast и go/types на Go, используя API линтера. Даже простые проверки требуют много кода. go/analysis призван упростить картину тем, что "фреймворк" у линтеров становится практически идентичным, но он не решает проблему сложности технической реализации самих диагностик. Когда вы пишите анализатор для Go, вашей конечной целью является взаимодействие с AST и типами, но перед тем, как вы это сможете сделать, исходные коды нужно правильным образом "загрузить". Если упрощённо, в понятие загрузки входит парсинг, проверка типов и импортирование зависимостей. Первым шагом в упрощении этого пайплайна стал пакет go/loader, который позволят "загрузить" всё нужное через пару вызовов. Всё было почти хорошо, а потом он стал deprecated в пользу go/packages. go/packages имеет немного улучшенное API и, в теории, хорошо работает с модулями. Теперь для написания анализаторов лучше всего не использовать ничего из выше перечисленного напрямую, потому что go/analysis дал go/packages то, чего не было ни у одного предыдущего решения — структуру для вашей программы. Теперь мы можем использовать диктуемую go/analysis парадигму и переиспользовать работу анализаторов более эффективно. У этой парадигмы есть спорные моменты, например, go/analysis хорошо подходит для анализа на уровне одного пакета и его зависимостей, но сделать на нём глобальный анализ без хитрых инженерных ухищрений будет не просто. go/analysis также упрощает тестирование анализаторов.  go-ruleguard — это утилита статического анализа, которая по умолчанию не включает в себя ни единой проверки. Правила ruleguard подгружаются на старте, из специального файла, декларативно описывающего паттерны кода, на которые стоит выдавать предупреждения. Этот файл может свободно редактироваться пользователями ruleguard. Перекомпилировать управляющую программу для подключения новых проверок не нужно, поэтому правила из ruleguard файлов можно называть динамическими. Управляющая программа ruleguard выглядит так: При этом analyzer реализован через пакет ruleguard, который и нужно использовать в случае, если вы хотите использовать его как библиотеку. Возьмём простой, но реальный пример: предположим, мы хотите избегать вызовов runtime.GC() в наших программах. В revive для этого уже есть отдельная диагностика, она называется "call-to-gc". А теперь сравните с тем, как это делается в go-ruleguard: Ничего лишнего, только то, что действительно важно — runtime.GC и сообщение, которое нужно выдавать в случае срабатывания правила. Вы можете спросить: и это всё? Я специально начал с такого простого примера, чтобы показать, как много кода может потребоваться для очень тривиальной диагностики в случае традиционного подхода. Обещаю, дальше будут более захватывающие примеры. В go-critic есть диагностика rangeExprCopy, которая находит в коде потенциально неожиданные копирования массивов. Вот этот код итерируется по копии массива: Исправление этой проблемы заключается в добавлении одного символа: Скорее всего, вам это копирование не нужно, а производительность исправленного варианта всегда лучше. Можно ждать, пока Go компилятор станет лучше, а можно детектировать такие места в коде и поправить их уже сегодня с помощью того же go-critic. Эту диагностику можно реализовать на нашем DSL (файл rules.go): Правило находит все циклы for-range, где используются обе итерируемые переменные (именно этот случай ведёт к копированию). Итерируемое выражение $x должно быть addressable и его размер должен быть выше выбранного порога в байтах. Report() определяет сообщение, которое нужно выдавать пользователю, а Suggest() описывает quickfix шаблон, который может использоваться в вашем редакторе через gopls (LSP), а также интерактивно, если ruleguard вызван с аргументом -fix (мы ещё к этому вернёмся). At() привязывает предупреждение и quickfix к конкретной части шаблона. Нам это необходимо, чтобы заменить $x на &$x, а не переписать весь цикл. И Report(), и Suggest(), принимают строку, в которую можно интерполировать захваченные шаблоном из Match() выражения. Предопределённая переменная $$ означает "весь захваченный фрагмент" (как $0 в регулярных выражениях). Создадим файл rangecopy.go: Теперь мы можем запустить ruleguard: Если после этого мы посмотрим в rangecopy.go, то увидим исправленный вариант, потому что ruleguard был вызван с параметром -fix. Простейшие правила можно отлаживать и без создания rules.go файла: Благодаря использованию go/analysis/singlechecker у нас есть опция -c, которая позволяет выводить указанное строк контекста вместе с самим предупреждением. Управление этим параметром немного контринтуитивно: значение по умолчанию равно -c=-1, что означает "без контекста", а -c=0 будет выводить одну строку контекста (ту, на которую указывает диагностика). Вот ещё несколько интересных возможностей DSL: Больше информации об используемом DSL можно найти в docs/dsl.md. Если для правила нет вызова Report(), то будет использоваться сообщение, выводимое из Suggest(). Это позволяет в некоторых случаях избежать дублирования. Фильтры типов и подвыражений могут проверять различные свойства. Например, полезными являются свойства Pure и Const: Для package-qualified имён в Where() условиях нужно использовать метод Import(). Для удобства, все стандартные пакеты импортированы за вас, поэтому в примере выше нам не нужно делать дополнительных импортов. Поддержку quickfix за нас реализует go/analysis. В модели go/analysis, анализатор генерирует диагностики и факты. Диагностики отправляются пользователям, а факты предназначены для использования другими анализаторами. Диагностика может иметь набор предлагаемых исправлений, каждое из которых описывает как нужно изменить исходные коды в указанном диапазоне, чтобы устранить проблему, найденную диагностикой. Официальное описание доступно в документе go/analysis/doc/suggested_fixes.md.  Попробуйте ruleguard на своих проектах, а в случае, если вы нашли баг или хотите попросить новую фичу, откройте issue. Если вам всё ещё сложно придумать применение ruleguard, вот примеры: Планы по развитию ruleguard на ближайшее будущее: Making developer tools & video games